Процессы разработки — постоянная тема обсуждения как внутри команд, так и на различных конференциях.
И, конечно же, их оптимизация — постоянная головная боль всех, кто так или иначе руководит разработкой.
Когда-то я был младшим разработчиком и очень не любил слово «процессы».
Все эти регулярные встречи и прочее общение казались глупыми, отвлекающими от значимой работы (написание кода, конечно).
Думаю, этот этап случался в жизни каждого, кто занимался разработкой; но на данном этапе здоровый регулярно повторяйте: любую деятельность можно оптимизировать (например, вообще отменить), а иногда ощущение бессмысленности происходящего оказывает поистине целительный эффект. 
Наш следующий проект мы решили посвятить процессам разработки.
Встреча лидеров группы , который состоится вечером 17 июня в московском офисе Яндекс.
Регистрация открыта! Наши эксперты согласились быть:
- Анатолий анатоликс Орлов, технический директор Ozon
- Алексей Катаев деусдеорум , руководитель отдела разработки программного обеспечения, SkyEng
- Александр Гутман, технический директор JoomPay
- Евгений Парамонов, руководитель отдела развития поискового микширования, Яндекс
- Андрей Плахов Я искатель , руководитель отдела поискового функционала, Яндекс
1. На какой основе построены процессы в вашей компании? 2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой процент — индивидуальными навыками? 3. Существуют ли ситуации, в которых тимлид имеет полное право игнорировать какие-либо процессы? 4. Расскажите страшилку из своего опыта со словом «процесс».Под катом много огня, сарказма в адрес авторов вопросов, самых разных мнений и, конечно, страшных историй.
Анатолий Орлов
анатоликс , технический директор, Озон
1. На какой основе построены процессы в вашей компании? Мы стараемся структурировать все процессы так, чтобы от идеи до реализации проходило как можно меньше времени.
В программистском сообществе такой подход называют «черт возьми в продакшене», и это выражение часто употребляется в негативном ключе.
При этом с точки зрения бизнеса гораздо разумнее быстро запустить проект или фичу, протестировать гипотезу и, если всё работает, довести до целевого состояния.
Эта идеология лежит в основе всех процессов: микросервисы, которые удобно развертывать отдельно; автоматическое развертывание путем слияния в ветку; вертикальные команды, в которых сидят вместе продуктовики, программисты, тестировщики и дизайнеры и имеют право не согласовывать изменения в своей зоне ответственности с кем-либо посторонним и т. д. 2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой процент — индивидуальными навыками? Считать проценты неправильно.
Наверное, стоит посчитать примерно так: умение определяет, насколько сложными системами вы сможете управлять, индивидуальная продуктивность специалистов определяет, насколько быстро вы сможете это сделать.
А плохие процессы и архитектура замедляют работу, это налог на неэффективность.
Налог может быть любым, в принципе, в некоторых компаниях он даже 100%, но такие организации обычно долго не живут (если, конечно, это не ГБУ «Жилищник свиблово»).
3. Существуют ли ситуации, в которых тимлид имеет полное право игнорировать какие-либо процессы? Всегда.
Если вы понимаете, что процесс скорее мешает вам, чем помогает, вы должны его изменить.
С другой стороны, это не значит, что вы можете принять такое решение в одиночку: договоритесь об этом с коллегами, а при необходимости и с начальством, чтобы не получилось так, что вы работаете по шаблону.
новый процесс, а команда и вся компания работают по старому, и в результате вообще ничего не работает. 4. Расскажите ужасную историю из своего опыта со словом «процесс».
Давайте я лучше напишу о принципе инверсии процесса на нескольких пугающих примерах.
Программистам хорошо известен принцип инверсии зависимостей, и то же самое относится и к процессам.
Его следует использовать примерно в следующих случаях: допустим, вы приходите в HR открывать вакансию, и вас просят заполнить 5-страничную анкету о том, кого вы собираетесь искать.
Или приходишь просить денег на что-то заведомо необходимое, а тебя просят написать служебную записку.
Этот процесс зачастую оказывается сломанным и бюрократизированным, ведь анкету пишут вам, а другим это облегчает (а то и нет) жизнь.
В результате у нас нет никакого механизма, чтобы договориться о том, что должно быть в анкете – 2 строки или 5 страниц.
Применение принципа инверсии процессов здесь выглядит так: человеку необходимо объяснить, зачем ему вакансия, а HR сам заполняет анкету, или финансист – памятку.
Обычно в этом случае получается, что никто не хочет целый день заполнять 5-страничные формы и писать служебные записки, и процесс сразу становится эффективным, без каких-либо последствий.
А для конечного клиента этот процесс превращается в «написание одного связного, общего предложения в работающем чате».
Алексей Катаев
деусдеорум , руководитель отдела разработки программного обеспечения, SkyEng
1. На какой основе построены процессы в вашей компании? У нас 284 репозитория на Github: вы можете найти код на любом языке программирования.
Кроме того, среди наших 20 команд разработчиков вы наверняка найдете даже водопад. Формирование процессов раньше оставляли на усмотрение тимлидов: быстрый старт проекта и разработка базовой платформы с 7-летней историей требуют другого подхода.
На еженедельных собраниях руководителей команд мы обменивались лучшими практиками, и они постепенно распространялись по всей компании.
В нынешних масштабах это не работает: кому-то из руководителей не хватает опыта, кому-то не хватает времени.
Рост энтропии начинает вызывать проблемы.
Весь последний год я распространял наши наработки по всем командам, балансируя между продажами и тем, что «так делать — это точно хорошо».
Легче внедрить правильные процессы при создании команды, а еще проще, когда из успешной команды отделяется тимлид: не нужно объяснять или продавать, он знает, что это работает. 2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой процент — индивидуальными навыками? По моему опыту - 100%.
Даже если разработчик-одиночка пишет код для себя, он все равно следует процессу, каким бы простым он ни был.
Если перефразировать вопрос: «насколько может надоесть команде крутых разработчиков изменение процессов», то мой ответ будет «очень».
Важно начать не с процесса code review, повышения зарплаты и обратной связи, а с базовых вещей — планирования, расстановки приоритетов, общения с бизнесом.
Кстати, многие крутые разработчики не появятся сами по себе без качественного процесса найма.
3. Существуют ли ситуации, в которых тимлид имеет полное право игнорировать какие-либо процессы? Когда возникает непредвиденная ситуация, к которой никто не готов.
Я сразу вспоминаю РКН, который когда-то запретил десятки наших API на Amazon. Мы тогда забыли о Канбане, о правильной постановке задач и в постоянных телефонных звонках на лету придумывали план действий.
Все было восстановлено в течение 24 часов.
4. Расскажите ужасную историю из своего опыта со словом «процесс».
Есть жуткая история о том, как супервайзер бесконечно перерождал процесс выплаты потребителем зарплаты.
И он вылетел с ошибкой, успев отправить запрос на платежный шлюз.
Но я не могу сказать об этом публично :)
Александр Гутман , технический директор, JoomPay
1. На какой основе построены процессы в вашей компании? Процессы в нашей компании только начинаются.
Мы используем OKR для ежеквартального планирования.
На более низком уровне мы используем в нем доски YouTrack и Agile для планирования разработки.
Мы используем Канбан.
Не в смысле «мы заморачиваемся максимальным количеством задач в каждом состоянии», а в смысле «нам лень переносить задачи из спринта в спринт».
Предшественником YouTrack с досками была таблица в Excel со всеми задачами и ответственными.
И это тоже сработало хорошо.
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой процент — индивидуальными навыками? Судя по всему, вопрос содержит предположение, что успех команды определяется исключительно правильными процессами и навыками, а сумма процентов должна составлять 100. Но есть и другие важные факторы: ресурсы или, например, случайность.
Поэтому я отвечу: 10% процессов и 10% мастерства.
С другой стороны, не очень понятно, как назвать процент влияния каждого фактора.
Почти каждый сложный проект может провалиться из-за плохих процессов или полного отсутствия индивидуальных навыков.
Поэтому мой ответ: 99% процессов и 99% мастерства.
В-третьих, если говорить о нетривиальных проектах и конкуренции между командами, процессы скучны, и у каждого должны быть какие-то разумные процессы, но определяющим фактором может стать индивидуальное мастерство.
Итак, окончательный ответ: 10% процесса и 20% навыков.
3. Существуют ли ситуации, в которых тимлид имеет полное право игнорировать какие-либо процессы? Бывают ситуации, в которых каждый может игнорировать что угодно.
В частности, тимлид — любые процессы.
Но я бы не стал так выделять лидера команды.
Здесь нужен некий консенсус внутри команды: процессы несовершенны, правила не универсальны, нужно использовать здравый смысл.
Например, выкатывать багфикс во время зависания нужно потому, что это логично, а не потому, что тимлид имеет на это право.
Даже если это не было оговорено заранее и правил на этот случай нет. 4. Расскажите ужасную историю из своего опыта со словом «процесс».
Однажды меня попросили ответить на вопрос: «Расскажите мне ужасную историю из вашего опыта работы со словами».
Евгений Парамонов , руководитель отдела развития поискового микширования, Яндекс
1. На какой основе построены процессы в вашей компании? Мы любим гибкие принципы.
Команда строит всю свою работу таким образом, чтобы максимально ускорить достижение целей компании и моральный дух коллектива в кратчайшие сроки.
Поскольку один из принципов agile гласит, что «люди и взаимодействия важнее процессов и инструментов», первое, что мы сделали, — это исправили базовые правила Scrum. Внутри команды мы продвигаем следующие принципы:
- Каждый из нас одновременно и дровосек, и ювелир (аналитик/тестер/разработчик)
- У каждого из нас есть сильные стороны (помогите другу/не стесняйтесь попросить)
- Каждый из нас определяет, как будет выглядеть конечный продукт (за каждым направлением есть ответственный человек)
Например, уже в процессе проведения эксперимента ему в голову приходит новая гениальная фича, он быстро ее реализует, раскатывает и проводит еще один эксперимент. На каждый месяц мы ставим цель, которой хотим достичь, и еженедельно проверяем свой прогресс.
Это дает нам гибкость, потому что… даже в течение недели мы можем менять планы, если это поможет нам достичь цели месяца.
При такой организации процесса участие менеджеров минимально, а команда приобретает мобильность и долгосрочную заинтересованность.
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой процент — индивидуальными навыками? Время движется вперед, мир меняется и вместе с ним меняются и наши процессы.
Мастерство – это:
- установить процесс, который работает на результаты;
- выявить проблему в текущих процессах и исправить ее;
- донести до людей понимание того, почему процесс работает именно так.
Моя команда занимается сразу тремя глобальными направлениями: исследованиями, машинным обучением и инфраструктурой (а по сути еще и продуктовой работой).
В этих сферах довольно сложно заранее выстроить процессы для всех возможных сценариев.
Зачастую успех во многом определяется профессиональной интуицией исполнителя и его руководителя.
3. Существуют ли ситуации, в которых тимлид имеет полное право игнорировать какие-либо процессы? Если процессы выстроены умело, то это маловероятно.
Хорошо структурированный процесс, скорее всего, построен на чужих ошибках.
Но, как я сказал выше, мы все время движемся вперед и мир меняется, поэтому рано или поздно возникнет ситуация, когда процесс придется игнорировать или менять.
Руководитель команды несет ответственность за вклад своей команды в достижение целей компании, и если он понимает, что действовать нужно здесь и сейчас, а текущие процессы точно не готовы к такой ситуации, ему обязательно нужно принять меры.
новый путь.
При таком выборе стоит оповестить всех, кого могут затронуть ваши действия.
Рассмотрим вымышленную ситуацию:
- менеджер случайно внес изменения в файл конфигурации и автодеплой выкатил его через 15 секунд;
- поиском становится невозможно пользоваться, страдают 100% пользователей;
- мониторинг вызывает тимлида и дежурного разработчика и сообщает, что всё плохо, к счастью в лог сыпятся ошибки и определенно ясно, какой компонент вызвал повреждение.
- создать билет;
- прикрепите туда всю отладочную информацию и аналитику;
- Исправьте это с помощью проверки кода.
Нам нужно действовать сейчас.
Если есть возможность откатить этот конфиг, откатите его.
В противном случае отключите весь компонент. Здесь и сейчас.
Разбирательства будут позже.
4. Расскажите ужасную историю из своего опыта со словом «процесс».
Страшная история со словесным процессом случилась, когда мы были молодыми и зелеными.
Мы услышали слово agile – стильный, модный, молодежный.
И мы ввели спринты.
Поначалу было круто: появился новый тип планирования.
Затем задачи начали переходить из спринта в спринт. Менеджер спросил нас: «КогдаЭ» Мы ответили: «Завтра».
Сроки, конечно, увеличили втрое, но в спринты мы все равно не вписывались.
Постепенно мы начали терять мораль.
Задачи накапливались; менеджер не понимал, что происходит; ситуация становилась неконтролируемой.
В результате мы на какое-то время отказались от гибких методологий.
Мораль этой истории такова: прежде чем внедрять новый процесс, нужно четко понимать, почему он делается и чем он лучше текущего положения дел.
Андрей Плахов
Я искатель , руководитель отдела поискового функционала, Яндекс
1. На какой основе построены процессы в вашей компании? Яндекс — очень крупная компания и очень и очень демократичная.
Какие бы обобщения я здесь не писал, где-то будет сервис Яндекс.
Boots, который окажется устроен совсем по-другому.
В тех местах, которые я наблюдаю, это работает так.
Для крупномасштабных процессов существуют строгие стандарты.
Четко описано, как определяются цели подразделений на полгода-год, как мы договариваемся о том, что считать успехом, а что провалом.
Как устанавливается, изменяется и влияет грейд сотрудника, как выплачиваются премии и опции, как организуется прием на работу и переводы между подразделениями и т.д. Но на уровне микроменеджмента почти везде команда сама определяет, по каким правилам она будет жить.
Оборачиваемость задач, график и содержание рабочих встреч, какие-то стендапы, спринты, вот и все.
Некоторые люди организуют идеальную схватку «прямо как в книге»; в некоторых небольших командах, наоборот, царит анархия.
Однако даже самые анархисты в какой-то момент понимают, что жить «как получилось» не оптимально.
А поскольку люди умные, это приходит быстро.
Насколько я знаю, водопадов нет (хотя за аппаратные команды не ручаюсь).
Я, как руководитель отдела, требую достаточно скромного стандарта процессов в моем отделе: должна быть возможность в любой момент увидеть, у кого какие конкретные задачи выполняются, как долго они висят в этом состоянии и кто Какие задачи выполнил недавно.
Для этого достаточно использовать онлайн-канбан-доску поверх стандартного трекера задач компании (теоретически в этом нет необходимости, но на практике в итоге все команды получают именно это).
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой процент — индивидуальными навыками? В общем, самое главное — успех бизнес-модели.
Если организация не придумала, что, кому и как продавать, то ей не помогут ни идеальные процессы, ни гениальные разработчики.
Поэтому предположим, что бизнес работает, и речь идет о долгосрочном развитии, качестве продукции, диверсификации и т. д. Тогда ответ во многом зависит от размера команды.
Успех команды из пяти человек практически на сто процентов определяется людьми.
Успех компании из пятисот и более человек практически на сто процентов определяется правильной организацией.
Карго-культ, когда небольшой стартап пытается жить по правилам, придуманным, скажем, IBM, может быть столь же вреден, как и принцип Питера, когда бывший «лидер» становится «сотником», но пытается жить по-старому.
способ.
Надо также сказать, что внутри гигантских промышленных гигантов вполне можно себе представить весьма замкнутые коллективы из нескольких человек.
Но такое положение вещей, к сожалению, сочетает в себе худшие стороны обоих миров, а не наоборот. Группа слабых людей не сможет сделать ничего толкового даже с готовой инфраструктурой, а неправильный процесс разбросает по шестерням даже звездную команду, и этого никто не заметит. 3. Существуют ли ситуации, в которых тимлид имеет полное право игнорировать какие-либо процессы? Конечно, есть, и слово «огонь» здесь очень уместно.
Если:
- ситуация ненормальная,
- быстро портится, если оставить его на волю случая,
- и этому можно помочь быстрым и решительным вмешательством, тогда к черту правила и «правильность»!
Совершенно непонятно, почему.
Какая-то мистика.
4. Расскажите ужасную историю из своего опыта со словом «процесс».
С самым страшным процессом в своей жизни я столкнулся очень давно, ещё до Яндекса, когда занимался разработкой компьютерных игр.
Над первой игрой молодой, но богатой и очень амбициозной компании, только что переехавшей в новый офис, работало более ста человек.
Более того, любое расходование любой суммы денег должно было быть одобрено генеральным директором.
Купить 50 серверов? Должен ли программист заменить сломанный стул на новый? Заказать обеды на следующую неделю? У офис-менеджера закончились скрепки? Все решает один и тот же человек, на столе растут стопки документов.
Как нетрудно догадаться, из-за этого «процесса» случались перебои даже с туалетной бумагой.
Чтобы правильно представить весь ужас происходящего, стоит добавить, что генеральный директор совмещал эту роль с ролью креативного директора (как сейчас сказали бы СРО) и с ролью главного дизайнера игры.
.
Следующая встреча, на которой вы еще можете присутствовать регистр , состоится 17 июня 2019 года в московском офисе Яндекс.
Там вы сможете задать вопросы спикерам и поделиться своим опытом.
Теги: #Карьера в ИТ-индустрии #Управление разработкой #встречи #Конференции #управление персоналом #процессы #тимлид-митап
-
Интеграция Crowdsec В Kubernetes
19 Oct, 24 -
Киев. Воскресенье.
19 Oct, 24 -
Снежный Барс 64Бит
19 Oct, 24 -
Постгрес. Выборка N Случайных Записей
19 Oct, 24
