company_banner

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

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


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




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

    Яндекс
    483,11
    Как мы делаем Яндекс
    Поделиться публикацией

    Комментарии 12

      +2
      Про инверсию процессов — отлично! Надо применять в жизни.
        0
        Еще логирование настройте чтобы было видно в какой области, как часто и кто любит «инверсировать» процессы. Поможет отдебажить неправильные процессы.
        +4
        Замечу, что Яндекс исказил смысл всей фразы написав «фигак-фигак», все было не так!
        • НЛО прилетело и опубликовало эту надпись здесь
          • НЛО прилетело и опубликовало эту надпись здесь
              0

              А в Петербурге вы подобных мероприятий не проводите?

                0
                Пока нет. Приезжайте к нам в Москву! :)
                –1
                Хорошо написано, легко читается. У всех Лидов прослеживается одна мысль в промерах: менеджмент мешает нам жить, творить, быть свободными, но они платят нам зарплату, поэтому приходится договариваться. :) Вспомнил анекдот: Пришел к выводу, что наш кот относится ко мне, как к богу. То есть, игнорирует мое существование до тех пор, пока ему от меня что-то не понадобится.
                • НЛО прилетело и опубликовало эту надпись здесь
                  0

                  Вы правы, что статья несёт именно этот посыл, но я смотрю на это со стороны заказчика, менеджмента и интерпретирую по другому их небольшие замечания. :) Команды не работают для своего удовольствия, и если Лиды пишут это, то это определенное лукавство. Они создают продукты для бизнеса, который определяет сроки и диктует свои правила.

                  • НЛО прилетело и опубликовало эту надпись здесь
                    +1
                    А можно на следующую встречу пригласить лидеров рынка, например, ребят из Google, MS, Facebook? Всегда хочется узнать про лучшие практики.

                    Кроме этого почему обошли такие компании как EPAM, Luxoft и т.д.?
                    Заказная разработка отличается от продуктовой, и там много своих нюансов в процессах.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое