Как устроены процессы разработки в различных компаниях
Процессы разработки — постоянная тема для дискуссий как внутри команд, так и на различных конференциях. И, конечно, их оптимизация является постоянной головной болью для всех, кто так или иначе управляет разработкой.
Когда-то я был младшим разработчиком и ужасно не любил слово «процессы». Все эти регулярные встречи и прочее общение казались глупостями, отвлекающими от содержательной работы (написания кода, конечно). Думаю, такой этап случался в жизни у каждого, кто занимался разработкой;, но такому этапу полезно повторяться регулярно: любую деятельность можно оптимизировать (например, вообще отменив), и иногда ощущение бессмысленности происходящего оказывает поистине целебное действие.
Мы решили посвятить процессам разработки наш следующий Team Leader Meetup, который пройдёт вечером 17 июня в московском офисе Яндекса. Регистрация открыта!
Нашими экспертами согласились быть:
- Анатолий anatolix Орлов, CTO, Ozon
- Алексей Катаев deusdeorum, Head of Software Development, SkyEng
- Александр Гутман, CTO, JoomPay
- Евгений Парамонов, руководитель разработки поисковых подмешиваний, Яндекс
- Андрей Плахов yafinder, руководитель отдела функциональности поиска, Яндекс
Сегодня они отвечают на некоторые вопросы, чтобы подготовить будущую дискуссию:
1. На какой основе построены процессы у вас в компании?
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?
3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?
4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»
Под катом — много огня, сарказм в адрес авторов вопросов, максимально различные мнения и, конечно, страшные истории.
1. На какой основе построены процессы у вас в компании?
Мы стараемся все процессы строить так, чтобы от идеи до реализации проходило как можно меньше времени. В программистском community такой подход называют «фигак-фигак и в production», и часто используют это выражение в негативном ключе. При этом с точки зрения бизнеса, гораздо разумнее быстро запустить проект или фичу, проверить гипотезу, и если все работает, допилить до целевого состояния.
Эта идеология и лежит в основе всех процессов: микросервисы, которые удобно деплоить отдельно; деплой автоматически по merge в ветку; вертикальные команды, которые содержат в себе product«а, программистов, тестировщиков и дизайнеров, сидящих вместе и имеющие права не согласовывать ни с кем снаружи изменения в своей зоне ответственности, и т. п.
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?
Проценты считать — неправильно. Наверное, стоит расчет вести примерно так: мастерство определяет, насколько сложные системы вы можете запускать, индивидуальная производительность специалистов — насколько быстро вы способны это делать. А плохие процессы и архитектура замедляют работу, это налог на неэффективность. Налог может быть любым, в принципе в некоторых компаниях даже 100% бывает, но долго такие организации обычно не живут (если это не «ГБУ Жилищник Свиблово», конечно).
3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?
Всегда. Если вы понимаете, что процесс вам мешает, а не помогает — вы должны его менять. С другой стороны, это не значит, что вы можете принять такое решение единолично: договоритесь об этом с коллегами, и если надо, с начальством, чтобы не оказалось, что вы работаете по новому процессу, а команда и вся компания — по старому, и в результате вообще ничего не работает.
4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»
Давайте я лучше напишу про принцип инверсии процессов с несколькими страшными примерами. Программистам хорошо известен принцип инверсии зависимостей, так вот в процессах есть то же самое.
Применять его нужно примерно в следующих случаях: допустим, ты приходишь в HR открывать вакансию, а они тебя просят заполнить 5-страничную анкету о том, кого ты собираешься искать. Или приходишь попросить денег на что-то очевидно нужное, и тебя просят написать служебную записку.
Вот этот процесс часто оказывается сломанным и бюрократическим, потому что писать анкету тебе, а жизнь она облегчает (или даже нет) другим. В результате у нас нет никакого механизма, чтобы договориться, что должно быть в анкете — 2 строчки или 5 страниц.
Применение принципа инверсии процессов здесь выглядит так: нужно, чтобы человек объяснил, зачем ему открыть вакансию, а HR сам заполнил анкету, или финансы — служебную записку. Обычно в этом случае оказывается, что целый день заполнять 5 страничные анкеты и писать служебные записки не хочется никому, и процесс немедленно становится эффективным, без каких-либо последствий. А для конечного заказчика процесс превращается в «напишите одно связное распространенное предложение в рабочий инструмент-чатик».
1. На какой основе построены процессы у вас в компании?
У нас на гитхабе 284 репозитория: можно найти код на любом языке программирования. Так же и среди наших 20 команд разработки, наверное, можно отыскать даже waterfall. Формирование процессов раньше отдавали на откуп тимлидам: быстрый старт проекта и развитие core-платформы с 7-летней историей требуют разного подхода. На еженедельных встречах тимлидов мы обменивались лучшими практиками и они медленно распространялись по компании.
На текущем масштабе это не работает: кому-то из тимлидов не хватает опыта, кому-то — времени. Растущая энтропия начинает приносить проблемы. Последний год я распространяю наши best practices на все команды, балансируя между sales и «делаем так, это точно хорошо». Проще внедрять правильные процессы при создании команды, ещё проще, когда тимлид отпочковывается от успешной команды: не нужно ни объяснять, ни продавать, он знает — это работает.
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?
По моему опыту — 100%. Даже если одинокий разработчик пишет код для себя, он всё равно следует процессу, пусть и простому. Если перефразировать вопрос: «насколько можно забустить команду крутых разработчиков, изменив процессы», мой ответ будет — «очень сильно». Важно начать не с процесса код-ревью, повышения зарплат и обратной связи, а с базовых вещей — планирование, определение приоритетов, общение с бизнесом. Кстати, много крутых разработчиков без крутого процесса найма сами собой не появятся.
3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?
Когда возникает непредвиденная ситуация, к которой никто не готов. Сразу вспоминается РКН, который однажды забанил десятки наших API в Amazon. Мы тогда забыли о Kanban, о правильной постановке задач и в режиме постоянного созвона придумывали план действий на лету. В течение суток восстановили всё.
4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»
Есть страшная история о том, как супервизор бесконечно респавнил процесс консумера, который выплачивал зарплату. А тот падал с ошибкой, успевая отправить запрос в платежный гейт. Но я не могу её публично рассказывать :)
1. На какой основе построены процессы у вас в компании?
Процессы в нашей компании только зарождаются.
Для квартального планирования мы используем OKR.
Уровнем ниже для планирования разработки мы используем YouTrack и Agile-борды в нем. Мы используем канбан. Не в смысле «заморачиваемся с максимальным количеством тасков в каждом состоянии», а в смысле «ленимся переносить таски из спринта в спринт». Предшественником YouTrack-а c бордами была табличка в Excel со всеми задачами и ответственными. И тоже работало неплохо.
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?
Кажется, вопрос содержит пресуппозицию, что успех команды определяется исключительно правильными процессами и мастерством, и проценты в сумме должны давать 100.
Но ведь есть другие важные факторы: ресурсы или, например, рандом. Поэтому я отвечу: на 10% процессами и на 10% мастерством.
С другой стороны, не очень понятно, что называть процентом влияния каждого фактора. Почти каждый сложный проект можно провалить при помощи неправильных процессов или полного отсутствия индивидуального мастерства. Поэтому мой ответ: на 99% процессы и на 99% мастерство.
С третьей стороны, если говорить про нетривиальные проекты и про конкуренцию между командами, процессы — это скучно и какие-то разумные процессы должны быть у всех, а вот индивидуальное мастерство может стать дифферинициатором. Поэтому финальный ответ: на 10% процессами и на 20% мастерством.
3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?
Бывают ситуации, в которых кто угодно может игнорировать что угодно. В частности, тимлид — любые процессы.
Но я бы не стал вот так выделять тимлида. Тут нужен некий консенсус внутри команды: процессы несовершенны, правила неуниверсальны, нужно руководствоваться здравым смыслом.
Скажем, выкатывать багфикс во время фриза нужно, потому что это логично, а не потому что тимлид имеет право. Даже если про это не договорились заранее и правила на этот случай нет.
4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»
Однажды меня попросили ответить на вопрос «Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс».
Евгений Парамонов, руководитель разработки поисковых подмешиваний, Яндекс
1. На какой основе построены процессы у вас в компании?
Мы любим принципы agile. Всю нашу работу команда строит таким образом, чтобы максимизировать достижение целей компании и моральный дух коллектива в кратчайший срок.
Так как один из принципов agile гласит, что «люди и взаимодействие важнее процессов и инструментов», то первое, что мы сделали — поправили основные правила скрама.
Внутри команды мы пропагандируем следующие принципы:
- Каждый из нас и дровосек и ювелир (аналитик/тестировщик/разработчик)
- У каждого из нас есть сильные стороны (помогай товарищу / смело спрашивай)
- Каждый из нас определяет, как будет выглядеть конечный продукт (у каждого направления есть ответственный)
Разработчики самостоятельно проводят анализ задач, тестируют их и заводят АБТ-эксперименты. Вместе с CI/CD это убийственная связка, она позволяет нам двигаться максимально быстро, так как всем контекстом владеет каждый разработчик. Например, уже в процессе проведения эксперимента ему в голову приходит новая гениальная фича, он её быстро реализует, катит и проводит ещё один эксперимент.
На каждый месяц мы ставим цель, которую мы хотим достичь и еженедельно сверяем прогресс. Это даёт нам гибкость, т.к. даже в течение недели мы можем менять наши планы, если это способствует достижению цели месяца.
При такой организации процесса вовлечение менеджеров оказывается минимальным и команда приобретает мобильность и долгосрочную целеустремлённость.
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?
Время движется вперёд, мир меняется и вместе с ним меняются наши процессы.
Мастерство это:
- наладить работающий на результат процесс;
- разглядеть проблему в текущих процессах и исправить её;
- донести до людей понимание, почему процесс устроен именно так.
На примере своей команды я с твёрдой уверенностью могу сказать, что это соотношение в районе один к одному.
Моя команда занимается сразу трёмя глобальными направлениями: исследования, машинное обучение и инфраструктура (а на самом деле ещё и продуктовой работой).
В этих областях заранее построить процессы под все возможные сценарии довольно сложно. Часто успех сильно определяется профессиональной интуицией исполнителя и его куратора.
3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?
Если процессы выстроен с мастерством, то такое маловероятно. Грамотно выстроенный процесс, скорее всего, выстроен на чужих ошибках.
Но, как я уже говорил выше, мы всё время движемся вперёд и мир меняется, так что рано или поздно произойдёт ситуация, когда процесс придется проигнорировать либо поменять.
Тимлид отвечает за вклад своей команды в достижение целей компании и если он понимает, что здесь и сейчас надо действовать, а текущие процессы совершенно точно не готовы к такой ситуации, ему точно нужно идти по новому пути. При таком выборе стоит оповестить о своих действиях всех, кого они могут затронуть.
Рассмотрим выдуманную ситуацию:
- менеджер случайно внёс изменения в конфигурационный файл и автодеплой его выкатил через 15 секунд;
- поиском становится невозможно пользоваться, страдает 100% пользователей;
- тимлиду и дежурному разработчику звонит мониторинг и констатирует, что всё плохо, благо в лог сыплются ошибки и однозначно понятно, какая компонента навредила.
В данном случае инструкция выстроена максимально плохо и гласит:
- заведи тикет;
- приложи туда всю отладочную информацию и аналитику;
- почини через кодревью.
Если мы пойдём по такому пути и даже, предположим, сделаем всё очень оперативно, это займёт минимум минут 5. Пять минут страданий для живых пользователей!
В данной ситуации каждая секунда для нас подобна смерти. Действовать нужно прямо сейчас. Если есть возможность закатить обратно этот конфиг — закатывать. Иначе — отключать весь компонент. Здесь и сейчас. Разбирательства — потом.
4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»
Страшная история со словом процесс произошла тогда, когда мы были молоды и зелены. Мы услышали слово agile — стильно, модно, молодёжно. И внедрили у себя спринты.
Сначала это было прикольно: появился новый вид планирования. Затем задачи стали двигаться из спринта в спринт. Менеджер спрашивал нас: «когда?». Мы отвечали: «завтра». Сроки умножались, конечно, на три, но мы всё равно не вписывались в спринты.
Постепенно мы начали терять мораль. Задачи копились; менеджер не понимал, что происходит; ситуация становилась неуправляемой. В итоге мы на какое-то время отказались от гибких методологий.
Мораль этой истории такая: прежде чем внедрять у себя новый процесс, нужно совершенно чётко осознать, зачем это делается и чем это лучше текущего положения дел.
Андрей Плахов yafinder, руководитель отдела функциональности поиска, Яндекс
1. На какой основе построены процессы у вас в компании?
Яндекс — очень большая компания и очень, очень демократичная. Какое бы обобщение я здесь ни написал, найдется где-нибудь сервис Яндекс.Ботинки, который окажется устроен совершенно иначе.
В тех местах, которые я наблюдаю, устроено так. Есть строгий стандарт крупномасштабных процессов. Четко расписано, как определяются цели подразделений на полгода-год, как мы договариваемся, что считать успехом, а что провалом. Как устанавливается, меняется и на что влияет грейд сотрудника, как платятся премии и опционы, как устроен найм и переход между подразделениями и т.п.
А вот на уровне микроменеджмента почти везде то, по каким правилам будет жить команда, определяет она сама. Оборот задач, расписание и содержание рабочих встреч, какие-нибудь стендапы там, спринты, вот это всё. Кто-то устраивает у себя идеальный скрам «как в книжке», у каких-то небольших команд, наоборот, анархия. Впрочем, даже самые анархисты в какой-то момент понимают, что жить «как получится» — не оптимально. А, поскольку люди умные, приходит это быстро. Вот водопадов, насколько мне известно, нет (хотя за команды, занимающиеся железом, не поручусь).
Я, как руководитель отдела, требую довольно скромного стандарта на процессы в своем отделе: должно быть можно в любой момент времени посмотреть, у кого какие конкретные задачи в работе, сколько времени они в этом состоянии висят, и кто какие задачи закрыл недавно. Для этого достаточно использовать онлайновую Канбан-доску поверх стандартного для компании трекера задач (теоретически, это не необходимо, но на практике в итоге все команды приходят именно к этому).
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?
Вообще, самое главное — это успешность бизнес-модели. Если организация так и не придумала, что продавать, кому и как, то ни идеальные процессы, ни гениальные разработчики ей не помогут. Поэтому предположим, что бизнес работает, и речь о долгосрочном развитии, качестве продукта, диверсификации и т.п.
Тогда ответ очень зависит от размера команды. Успех команды из пяти человек почти на сто процентов определяется людьми. Успех компании из пятисот и более почти на сто процентов определяется правильной организацией. Карго-культ, когда маленький стартап пытается жить по правилам, придуманным, скажем, в IBM, бывает так же вреден, как и принцип Питера, когда бывший «звеньевой» становится «сотником», но пытается жить по-старому.
Ещё нужно сказать, что очень замкнутые команды из нескольких человек вполне представимы внутри гигантских индустриальных джаггернаутов. Но такое положение дел, к сожалению, сочетает худшие стороны обоих миров, а не наоборот. Группа слабых людей ничего толкового не осилит даже на готовой инфраструктуре, а неправильный процесс размажет и звёздную команду по шестеренкам, и никто этого не заметит.
3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?
Конечно, бывают, и слово «пожар» тут очень уместное. Если:
- ситуация нештатная,
- быстро ухудшается, если оставить её на самотёк,
- и в ней можно помочь быстрым, решительным вмешательством,
то к чёрту правила и «правильность»!
Главное — чтобы такие ситуации не доставляли тимлиду удовольствие, иначе мы рискуем через некоторое время обнаружить, что пожары вокруг него происходят заметно чаще, чем в среднем по организации. Совершенно непонятно почему. Мистика какая-то.
4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»
Самый страшный процесс в своей жизни я встретил давным-давно, ещё до Яндекса, когда занимался разработкой компьютерных игр. Над первой игрой молодой, но богатой и очень амбициозной компании, только что переехавшей в новый офис, работало больше ста человек. При этом любая трата любого количества денег должна была утверждаться у генерального директора. Купить 50 серверов? Заменить программисту сломанное кресло на новое? Заказать обеды на следующую неделю? У офис-менеджера закончились скрепки? Всё решает один и тот же человек, на столе растут стопки документов. Как несложно догадаться, перебои из-за такого «процесса» бывали даже с туалетной бумагой. Чтобы как следует представить жуть происходившего, стоит добавить, что генеральный директор совмещал эту роль с ролью креативного директора (как сейчас сказали бы, СРО) и с ролью главного дизайнера игры…
Следующая встреча, на которую ещё можно зарегистрироваться, состоится 17 июня 2019 года в московском офисе Яндекса. На ней можно будет задать вопросы докладчикам и поделиться своим опытом.
