Как устроены процессы разработки в различных компаниях

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Процессы разработки — постоянная тема для дискуссий как внутри команд, так и на различных конференциях. И, конечно, их оптимизация является постоянной головной болью для всех, кто так или иначе управляет разработкой.


Когда-то я был младшим разработчиком и ужасно не любил слово «процессы». Все эти регулярные встречи и прочее общение казались глупостями, отвлекающими от содержательной работы (написания кода, конечно). Думаю, такой этап случался в жизни у каждого, кто занимался разработкой; но такому этапу полезно повторяться регулярно: любую деятельность можно оптимизировать (например, вообще отменив), и иногда ощущение бессмысленности происходящего оказывает поистине целебное действие.




Мы решили посвятить процессам разработки наш следующий Team Leader Meetup, который пройдёт вечером 17 июня в московском офисе Яндекса. Регистрация открыта!


Нашими экспертами согласились быть:


  • Анатолий anatolix Орлов, CTO, Ozon
  • Алексей Катаев deusdeorum, Head of Software Development, SkyEng
  • Александр Гутман, CTO, JoomPay
  • Евгений Парамонов, руководитель разработки поисковых подмешиваний, Яндекс
  • Андрей Плахов yafinder, руководитель отдела функциональности поиска, Яндекс

Сегодня они отвечают на некоторые вопросы, чтобы подготовить будущую дискуссию:


1. На какой основе построены процессы у вас в компании?
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?
3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?
4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»

Под катом — много огня, сарказм в адрес авторов вопросов, максимально различные мнения и, конечно, страшные истории.


Анатолий Орлов anatolix, CTO, Ozon



1. На какой основе построены процессы у вас в компании?


Мы стараемся все процессы строить так, чтобы от идеи до реализации проходило как можно меньше времени. В программистском community такой подход называют «фигак-фигак и в production», и часто используют это выражение в негативном ключе. При этом с точки зрения бизнеса, гораздо разумнее быстро запустить проект или фичу, проверить гипотезу, и если все работает, допилить до целевого состояния.


Эта идеология и лежит в основе всех процессов: микросервисы, которые удобно деплоить отдельно; деплой автоматически по merge в ветку; вертикальные команды, которые содержат в себе product’а, программистов, тестировщиков и дизайнеров, сидящих вместе и имеющие права не согласовывать ни с кем снаружи изменения в своей зоне ответственности, и т. п.


2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?


Проценты считать — неправильно. Наверное, стоит расчет вести примерно так: мастерство определяет, насколько сложные системы вы можете запускать, индивидуальная производительность специалистов — насколько быстро вы способны это делать. А плохие процессы и архитектура замедляют работу, это налог на неэффективность. Налог может быть любым, в принципе в некоторых компаниях даже 100% бывает, но долго такие организации обычно не живут (если это не «ГБУ Жилищник Свиблово», конечно).


3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?


Всегда. Если вы понимаете, что процесс вам мешает, а не помогает — вы должны его менять. С другой стороны, это не значит, что вы можете принять такое решение единолично: договоритесь об этом с коллегами, и если надо, с начальством, чтобы не оказалось, что вы работаете по новому процессу, а команда и вся компания — по старому, и в результате вообще ничего не работает.


4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»


Давайте я лучше напишу про принцип инверсии процессов с несколькими страшными примерами. Программистам хорошо известен принцип инверсии зависимостей, так вот в процессах есть то же самое.


Применять его нужно примерно в следующих случаях: допустим, ты приходишь в HR открывать вакансию, а они тебя просят заполнить 5-страничную анкету о том, кого ты собираешься искать. Или приходишь попросить денег на что-то очевидно нужное, и тебя просят написать служебную записку.


Вот этот процесс часто оказывается сломанным и бюрократическим, потому что писать анкету тебе, а жизнь она облегчает (или даже нет) другим. В результате у нас нет никакого механизма, чтобы договориться, что должно быть в анкете — 2 строчки или 5 страниц.


Применение принципа инверсии процессов здесь выглядит так: нужно, чтобы человек объяснил, зачем ему открыть вакансию, а HR сам заполнил анкету, или финансы — служебную записку. Обычно в этом случае оказывается, что целый день заполнять 5 страничные анкеты и писать служебные записки не хочется никому, и процесс немедленно становится эффективным, без каких-либо последствий. А для конечного заказчика процесс превращается в «напишите одно связное распространенное предложение в рабочий инструмент-чатик».


Алексей Катаев deusdeorum, Head of Software Development, SkyEng



1. На какой основе построены процессы у вас в компании?


У нас на гитхабе 284 репозитория: можно найти код на любом языке программирования. Так же и среди наших 20 команд разработки, наверное, можно отыскать даже waterfall. Формирование процессов раньше отдавали на откуп тимлидам: быстрый старт проекта и развитие core-платформы с 7-летней историей требуют разного подхода. На еженедельных встречах тимлидов мы обменивались лучшими практиками и они медленно распространялись по компании.


На текущем масштабе это не работает: кому-то из тимлидов не хватает опыта, кому-то — времени. Растущая энтропия начинает приносить проблемы. Последний год я распространяю наши best practices на все команды, балансируя между sales и «делаем так, это точно хорошо». Проще внедрять правильные процессы при создании команды, ещё проще, когда тимлид отпочковывается от успешной команды: не нужно ни объяснять, ни продавать, он знает — это работает.


2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?


По моему опыту — 100%. Даже если одинокий разработчик пишет код для себя, он всё равно следует процессу, пусть и простому. Если перефразировать вопрос: «насколько можно забустить команду крутых разработчиков, изменив процессы», мой ответ будет — «очень сильно». Важно начать не с процесса код-ревью, повышения зарплат и обратной связи, а с базовых вещей — планирование, определение приоритетов, общение с бизнесом. Кстати, много крутых разработчиков без крутого процесса найма сами собой не появятся.


3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?


Когда возникает непредвиденная ситуация, к которой никто не готов. Сразу вспоминается РКН, который однажды забанил десятки наших API в Amazon. Мы тогда забыли о Kanban, о правильной постановке задач и в режиме постоянного созвона придумывали план действий на лету. В течение суток восстановили всё.


4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»


Есть страшная история о том, как супервизор бесконечно респавнил процесс консумера, который выплачивал зарплату. А тот падал с ошибкой, успевая отправить запрос в платежный гейт. Но я не могу её публично рассказывать :)


Александр Гутман, CTO, JoomPay



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 года в московском офисе Яндекса. На ней можно будет задать вопросы докладчикам и поделиться своим опытом.

Источник: https://habr.com/ru/company/yandex/blog/454864/


Интересные статьи

Интересные статьи

У нас было 2 проектных менеджера, 72 эксперта от производства, 33 высококлассных спеца из двух IT-команд, несколько десятков систем управления производством по всей стран...
Я начал писать код в моей комнате родительского дома, когда мне было 14. Помню, как читал всё, что мог достать с помощью своего медленного соединения с Интернетом. Затем, когда мне было 2...
Excel часто используется как универсальное средство для разработки бизнес-приложений. В этой статье я хочу сравнить, существующие без особых изменений уже более 30 лет, электронные таблиц...
Статья о том, как упорядочить найм1. Информируем о вакансии2. Ведём до найма3. Автоматизируем скучное4. Оформляем и выводим на работу5. Отчитываемся по итогам6. Помогаем с адаптацией...
Есть статьи о недостатках Битрикса, которые написаны программистами. Недостатки, описанные в них рядовому пользователю безразличны, ведь он не собирается ничего программировать.