Разработка в стартап-студии. Процессы, задачи, команда
Станислав Сурский, CTO Admitad Projects
Это первый материал из серии про разработку в рамках стартап-студии. В первой части CTO Admitad Projects Станислав Сурский рассказывает про отличия в подходе к разработке разных компаний, о том, как все происходит в ADP и, само собой, как последние глобальные события повлияли на разработчиков.
Я могу сравнивать, как устроена разработка в разных компаниях. Работал разработчиком и в интернет-магазинах, и фрилансером, есть небольшой опыт в веб-студии. Так же плотно трудился ведущим разработчиком в антивирусном вендоре и там же был руководителем разработки. Очень часто приходилось работать с людьми, которые в разработке ничего не понимают и, самое главное, не прислушиваются к тому, что разработчик и техкоманда им говорят. У них бизнес-задачи и требования, они приходят: «Дай мне «вчера» функционал». А такая разработка легко уляжется в годовой план… И, самое главное, обратную связь не слышат. Им рассказывают парни-девелоперы — не бывает чудес, есть воркфлоу: вот здесь планирование, декомпозиция, дальше анализ и самая малая часть, 30% — это написание кода. В ответ: «Нет-нет, это же легко, мне на прошлой неделе Вася-сосед точно такую же фигню делал за 2 недели, поэтому давайте, я в вас верю, мы сейчас с вами горы свернем!»
Подход к тому, как относятся к разработчикам уже слабо зависит от того ИТ-компания или «не ИТ». К примеру, если взять того же самого туристического оператора или интернет-магазин — у них деятельность напрямую связана с IT, у них основные каналы продаж там. Нет таких компаний уже, которые без IT. Точнее есть, но это уже в другом мире каком-то.
В гигантах ИТ-индустрии есть другой нюанс. Там все зависит от позиции и направления, в котором ты работаешь. В какую команду попадешь. Можно прийти гребцом на галеру: тебя посадят у весла и ты будешь долгие годы мозоли натирать в одном направлении, совершая раз за разом, день за днем одно движение, а есть команды или проекты, где ты будешь Разработчиком. С потенциалом. Сможешь влиять на какие-то решения. И, конечно же, безумная бюрократия. Недавно собеседовал человека на техлида — он работает в компании-подрядчике крупного телекома. Сейчас пилят личный кабинет для В2В., Он односложно отвечает на вопрос, почему уходит из компании — «бюрократия!». Как пример, миграция на более свежую версию фреймворк. Сам процесс написания кода, по его словам, занял, пусть, неделю, а утверждали и принимали решение о том, чтобы мигрировать, 9 месяцев. Это очень красочный и показательный пример.Эта ситуация мне видится не бюрократией ради бюрократии, а то что не те люди принимают решения. Выбор стека не должен уходить дальше технического директора, и то это когда «парни, мы какую-нибудь дичь на новом проекте покатаем, надо смотреть, как проект будет развиваться в ближайшие полгода», и после этого решение должна принимать сама команда. Взглянуть немного в будущее и подумать, как мы это будем обслуживать. А когда это уходит на уровень людей, которые не будут решать проблемы технического характера с производительностью или с обслуживанием кода, то это теряет всякий смысл.
У нас процессы с точки зрения больших корпораций максимально «расбюрократизированы». Хотя случались, конечно, моменты, когда «бюрократия» защитила бы нас от каких-то ошибок, но они были не настолько критичны, чтобы затягивать решения на те же самые полгода (это бы нас просто убило), да и стоимость ошибки невелика. Мы можем себе еще позволить ошибаться, но результат ошибок — опыт. Мы понимаем, как это решать быстро, мы копим рецепты, как нам позволить сохранять скорость в дальнейшем.
С точки зрения задач работа в ADP мало чем отличается от того, что в других IT-компаниях. Есть продукты внутренние и внешние — не важно. Внутренний продукт — это тот же самый корпоративный портал на Bitrix, внешний, когда к тебе приходит основатель нового проекта и ты уже с ним что-то решаешь. Над каждым из этих продуктов трудится одна команда, либо одна команда тащит несколько задач.
Самое интересное начинается, когда отрываешься от трекера задач и видишь самые важные отличия от других компаний. Это та самая атмосфера, та политика, что транслируют сверху. У нас много тех, кто не разбирается (да и не должен) в нюансах, тонкостях разработки. Или просто с малым опытом управления цифровыми продуктами. Но люди прислушиваются и слышат что им говорят. То есть, если они что-то не знают они пойдут, почитают или поспрашивают у кого-то и примут к сведению. В других компаниях это в меньшей степени наблюдалось, прямо в разы.
Внутри наших команд разработки самое главное — это отсутствие боязни ошибиться. Потому что, сравнивая с предыдущим опытом, если случилась какая-то ошибка, не важно по чьей вине — то ай-ай-ай, разбор, наказание и все такое. Здесь это очень сильно отличается — никого и не за какие косяки никогда не наказывают, не было такого что «вот такой плохой накосячил!» — косячат все. Мы разбираем ошибки, вносим их в регламенты и учим, что больше так не надо делать. На мой взгляд, это позволяет формировать атмосферу возможности ошибиться, желания учиться и свободы действия.
Может показаться, что подход, когда за ошибки, косяки и факапы по большому счет не наказывают, людей расслабляет больше нужного. Конечно, везде есть дураки, которые будут косячить, но это зависит от мотивации. Когда мы ищем нового разработчика, для меня важно, чтобы он своими словами озвучил следующую мысль — мне интересно писать код, и я хочу писать качественный код. Чтобы это была его личная морковка, и чтобы он этому следовал всегда! Эта внутренняя необходимость будет человека подталкивать. Он станет обращать внимание на свой прежний опыт, на ошибки, которые совершал, и стараться не делать их больше. Поэтому нам в первую очередь нужны ответственные разработчики.
Еще, конечно же, при собеседования потенциального сотрудника смотрю на общий бэкграунд, чем человек занимается, чем интересуется. Если придет разработчик, который, как под копирку под нашу вакансию, и будет второй, у которого точно такая же «копирка» в резюме, но он еще Arduino дома по вечерам крутит, то, естественно, приоритет второму — у него шире бэкграунд. Он может более широкий спектр вопросов решить, у него компетенций будет побольше, и как правило, с такими людьми просто интересно работать.
С формальной точки зрения при найме у нас ничего необычного. Все собеседования проходят в три этапа: знакомимся, тестовое, а потом техническое интервью. Вылавливаем может ли человек адекватно общаться, его техскил, и как быстро выполнил тестовое, не тормозит ли он, быстро ли фидбечил. Cледующие три месяца — испытательный срок, они показывают, вливается человек или нет.
Месяцы самоизоляции, конечно, много чего у нас перевернули. В общем-то, мем про технаря, который сидел все время за компом и потом удивленно спрашивает: «Карантин?! Какой карантин?!» — не хохма, а жизнь. Многие наши разработчики уже точно не вернутся в офис. Это не удаленщики, которые и брались изначально на удаленку, это именно те, кто до всего этого аккуратно приходил на работу, хотя присутствия «от и до» никто никогда не требовал. Когда все начиналось были опасения, что мы будем неэффективно работать, где-то будут просадки, но на практике не все так страшно. Половина разработчиков стала эффективнее работать именно из дома.Если по цифрам, то у меня прогноз такой. Из 100% тех, кто ходил в офисы, я думаю, процентов 50 перестанет это делать, процентов 30 будут в офисе 1–3 дня в неделю. Оставшиеся 20% — семейные и с детьми сказали, что будут фуллтайм.
Но лично для меня за это время пропала важная часть работы в офисе — социальная. Нет быстрых минутных встреч, когда вместо того, чтобы поговорить 3 минуты с коллегой на кофепоинте и прояснить вопросы, ты назначаешь колл и 30 минут про это разговариваешь. У меня сейчас есть дни, когда я сажусь на свой любимый балкон в 9 утра и встаю в 10 вечера, и в промежутке я не делаю ничего, кроме как разговариваю с компьютером. В этом я вижу большой минус: нагрузки стало больше, потому что нет быстрых коммуникаций, теперь нужно либо написать, либо позвонить. Созвониться долго, переписываться тоже долго — коммуникации стали долгие.
Я никогда не думал до этого, что мне будет так хотеться живого общения, обычного человеческого, пусть не столь продуктивного, когда ты четко планируешь все по часам. Но все же этот период заставил использовать и комбинировать решения. Теперь доказано, что при наличии мотивации люди могут совместно эффективно решать задачи на больших расстояниях. Вот это мне кажется очень важным.
