Процессы разработки — постоянная тема для дискуссий как внутри команд, так и на различных конференциях. И, конечно, их оптимизация является постоянной головной болью для всех, кто так или иначе управляет разработкой. Когда-то я был младшим разработчиком и ужасно не любил слово «процессы». Все эти регулярные встречи и прочее общение казались глупостями, отвлекающими от содержательной работы (написания кода, конечно). Думаю, такой этап случался в жизни у каждого, кто занимался разработкой; но такому этапу полезно повторяться регулярно: любую деятельность можно оптимизировать (например, вообще отменив), и иногда ощущение бессмысленности происходящего оказывает поистине целебное действие. 
 Мы решили посвятить процессам разработки наш следующий Team Leader Meetup, который пройдёт вечером 17 июня в московском офисе Яндекса. Регистрация открыта! Нашими экспертами согласились быть: Сегодня они отвечают на некоторые вопросы, чтобы подготовить будущую дискуссию: Под катом — много огня, сарказм в адрес авторов вопросов, максимально различные мнения и, конечно, страшные истории.  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. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы? Если процессы выстроен с мастерством, то такое маловероятно. Грамотно выстроенный процесс, скорее всего, выстроен на чужих ошибках. Но, как я уже говорил выше, мы всё время движемся вперёд и мир меняется, так что рано или поздно произойдёт ситуация, когда процесс придется проигнорировать либо поменять. Тимлид отвечает за вклад своей команды в достижение целей компании и если он понимает, что здесь и сейчас надо действовать, а текущие процессы совершенно точно не готовы к такой ситуации, ему точно нужно идти по новому пути. При таком выборе стоит оповестить о своих действиях всех, кого они могут затронуть. Рассмотрим выдуманную ситуацию: В данном случае инструкция выстроена максимально плохо и гласит: Если мы пойдём по такому пути и даже, предположим, сделаем всё очень оперативно, это займёт минимум минут 5. Пять минут страданий для живых пользователей! В данной ситуации каждая секунда для нас подобна смерти. Действовать нужно прямо сейчас. Если есть возможность закатить обратно этот конфиг — закатывать. Иначе — отключать весь компонент. Здесь и сейчас. Разбирательства — потом. 4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс» Страшная история со словом процесс произошла тогда, когда мы были молоды и зелены. Мы услышали слово agile — стильно, модно, молодёжно. И внедрили у себя спринты. Сначала это было прикольно: появился новый вид планирования. Затем задачи стали двигаться из спринта в спринт. Менеджер спрашивал нас: «когда?». Мы отвечали: «завтра». Сроки умножались, конечно, на три, но мы всё равно не вписывались в спринты. Постепенно мы начали терять мораль. Задачи копились; менеджер не понимал, что происходит; ситуация становилась неуправляемой. В итоге мы на какое-то время отказались от гибких методологий. Мораль этой истории такая: прежде чем внедрять у себя новый процесс, нужно совершенно чётко осознать, зачем это делается и чем это лучше текущего положения дел.  1. На какой основе построены процессы у вас в компании? Яндекс — очень большая компания и очень, очень демократичная. Какое бы обобщение я здесь ни написал, найдется где-нибудь сервис Яндекс.Ботинки, который окажется устроен совершенно иначе. В тех местах, которые я наблюдаю, устроено так. Есть строгий стандарт крупномасштабных процессов. Четко расписано, как определяются цели подразделений на полгода-год, как мы договариваемся, что считать успехом, а что провалом. Как устанавливается, меняется и на что влияет грейд сотрудника, как платятся премии и опционы, как устроен найм и переход между подразделениями и т.п.  А вот на уровне микроменеджмента почти везде то, по каким правилам будет жить команда, определяет она сама. Оборот задач, расписание и содержание рабочих встреч, какие-нибудь стендапы там, спринты, вот это всё. Кто-то устраивает у себя идеальный скрам «как в книжке», у каких-то небольших команд, наоборот, анархия. Впрочем, даже самые анархисты в какой-то момент понимают, что жить «как получится» — не оптимально. А, поскольку люди умные, приходит это быстро. Вот водопадов, насколько мне известно, нет (хотя за команды, занимающиеся железом, не поручусь). Я, как руководитель отдела, требую довольно скромного стандарта на процессы в своем отделе: должно быть можно в любой момент времени посмотреть, у кого какие конкретные задачи в работе, сколько времени они в этом состоянии висят, и кто какие задачи закрыл недавно. Для этого достаточно использовать онлайновую Канбан-доску поверх стандартного для компании трекера задач (теоретически, это не необходимо, но на практике в итоге все команды приходят именно к этому). 2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством? Вообще, самое главное — это успешность бизнес-модели. Если организация так и не придумала, что продавать, кому и как, то ни идеальные процессы, ни гениальные разработчики ей не помогут. Поэтому предположим, что бизнес работает, и речь о долгосрочном развитии, качестве продукта, диверсификации и т.п. Тогда ответ очень зависит от размера команды. Успех команды из пяти человек почти на сто процентов определяется людьми. Успех компании из пятисот и более почти на сто процентов определяется правильной организацией. Карго-культ, когда маленький стартап пытается жить по правилам, придуманным, скажем, в IBM, бывает так же вреден, как и принцип Питера, когда бывший «звеньевой» становится «сотником», но пытается жить по-старому. Ещё нужно сказать, что очень замкнутые команды из нескольких человек вполне представимы внутри гигантских индустриальных джаггернаутов. Но такое положение дел, к сожалению, сочетает худшие стороны обоих миров, а не наоборот. Группа слабых людей ничего толкового не осилит даже на готовой инфраструктуре, а неправильный процесс размажет и звёздную команду по шестеренкам, и никто этого не заметит. 3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы? Конечно, бывают, и слово «пожар» тут очень уместное. Если: Главное — чтобы такие ситуации не доставляли тимлиду удовольствие, иначе мы рискуем через некоторое время обнаружить, что пожары вокруг него происходят заметно чаще, чем в среднем по организации. Совершенно непонятно почему. Мистика какая-то. 4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс» Самый страшный процесс в своей жизни я встретил давным-давно, ещё до Яндекса, когда занимался разработкой компьютерных игр. Над первой игрой молодой, но богатой и очень амбициозной компании, только что переехавшей в новый офис, работало больше ста человек. При этом любая трата любого количества денег должна была утверждаться у генерального директора. Купить 50 серверов? Заменить программисту сломанное кресло на новое? Заказать обеды на следующую неделю? У офис-менеджера закончились скрепки? Всё решает один и тот же человек, на столе растут стопки документов. Как несложно догадаться, перебои из-за такого «процесса» бывали даже с туалетной бумагой. Чтобы как следует представить жуть происходившего, стоит добавить, что генеральный директор совмещал эту роль с ролью креативного директора (как сейчас сказали бы, СРО) и с ролью главного дизайнера игры... Следующая встреча, на которую ещё можно зарегистрироваться, состоится 17 июня 2019 года в московском офисе Яндекса. На ней можно будет задать вопросы докладчикам и поделиться своим опытом.