Команда разработки

У нас было 2 проектных менеджера, 72 эксперта от производства, 33 высококлассных спеца из двух IT-команд, несколько десятков систем управления производством по всей стране, а еще, разработчики КРОК и Группы НЛМК прежде не работали вместе.

Звучит как организационный ад, и это недалеко от истины. Но мы справились и теперь хотим поделиться опытом работы в объединенной команде НЛМК и КРОК в масштабном проекте по развитию информационных сервисов службы продаж.

На этот раз КРОК работал вместе с Группой НЛМК одной из самых крупных сталелитейных компаний с заводами в семи странах. Нашей объединенной команде предстояло масштабировать и усовершенствовать систему маркировки продукции так, чтобы, считав с этикетки QR-код, можно было получить исчерпывающую информацию о продукции через онлайн сервис.

Это только на первый взгляд все гвозди, арматура и металлические рулоны одинаковые. У каждого вида продукции своё назначение, технические характеристики и потребительские свойства.

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

Это не просто формальность. Сертификат качества в металлопродукции это как свидетельство о рождении и одновременно медицинская карта для человека. Без него сложно понять, например, подойдет ли арматура для строительства многоквартирного дома, выдержит ли она нагрузку.

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

Другое дело цифровой сертификат. Можно заверить его электронной подписью, добавить исчерпывающие характеристики товара и напечатать на каждой этикетке или бирке QR-код с уникальной ссылкой на все эти данные. А для проверки электронно-цифровой подписи существуют специальные общедоступные сервисы. В частности, подлинность ЭЦП не сложно проверить на портале Госуслуги.

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

Работа в тандеме

Группа НЛМК сотни видов продукции и заводы, похожие на маленькие города. Каждый с многолетней историей и собственными вычислительными центрами. Мягко говоря сильно непростое хозяйство.

В НЛМК сложный IT-ландшафт на каждом заводе, в каждом цехе свой парк оборудования и связанные с ним MES (manufacturing execution system) системамы планирования и управления производством. Это десятки цеховых систем управления, которые работают в разных часовых поясах, предоставляют данные в разное время и в разных форматах, а также системы корпоративного класса (ERP, CRM и пр.)

Чтобы реализовать QR-кодирование продукции, нам нужно было найти общий язык с системами на четырех российских площадках Группы НЛМК: Новолипецком комбинате, НЛМК-Урал, НЛМК-метиз и НЛМК-Калуга.

Катанка, моталка, прокатка, бунт, швеллер и подмотка лишь некоторые термины и слова, которые вошли в мой словарь за время работы с НЛМК, Марина Зиновьева, аналитик проекта, КРОК.

В подобных случаях необходимы и большой опыт системной интеграции в промышленности, и знание конкретного производства. Так что, обычный аутсорсинг здесь мало применим. Группа НЛМК предпочитает интегрированный подход над проектом работает объединенная команда разработчиков.

В нашем случае часть команды со стороны Группы НЛМК отвечала за общее видение системы, архитектуру и архитектурный контроль, инфраструктуру. Они предоставили экспертизу по MES. DevOps, проектирование, планирование работы и собственно разработка были на стороне КРОК.

Для разработчиков КРОК это был первый масштабный проект в такой тесной связке с командой НЛМК. И что могло пойти не так?

Старт проекта

Разработчики Группы НЛМК провели большую подготовительную работу, связались с ключевыми клиентами и выяснили их потребности, изучили процедуру выпуска сертификатов, продумали архитектуру будущей цифровой платформы.

Они ожидали от партнера такой же погруженности. Поэтому для команды КРОК проект стартовал будто с места в карьер. Через несколько часов после окончания конкурса раздался звонок:

Добрый день! Присылайте план проекта.

Здравствуйте, приятно познакомиться, сейчас пришлем.

Не спали ночь, но прислали.

Первые три недели команда КРОК планировала пустить на изучение текущих наработок и IT-ландшафта предприятия, но оказалось, что нужно показать первые результаты разработки уже через две недели после старта проекта. Это было жестко.

Для НЛМК проект оказался так важен, что они провели собеседования с каждым членом нашей команды, Ярослав Репной, менеджер проекта, КРОК.

Команда КРОК боялась, что за первые две три недели ничего не успеет. Напряжение росло, но на выручку пришел бизнес-заказчик. Он выделил задачи, которые помогли быстро выработать общие подходы к работе и видение проекта.

Пара коротких спринтов на практике доказала, что разработчики КРОК и Группы НЛМК могут продуктивно работать вместе. Появилось время, чтобы познакомиться с новыми коллегами и вникнуть в нюансы задачи.

Важно подчеркнуть, что разработка велась на базе Единой Цифровой Платформы (ЕЦП), которая развернута в НЛМК как целевая экосистема для внедрения новых цифровых продуктов. В основе подходов к созданию ЕЦП лежит гибридная IT-архитектура, задачей которой является сочетание коробочных IT-компонентов и открытой платформы. Платформа обеспечивает унифицированные технические компоненты и данные для построения сквозных сценариев, создания цифровых продуктов и приложений.

Не у каждой IT-компании есть аналогичные решения. Как правило, приходится внедрять такие решения у заказчика самим. Это сильно ускорило нашу работу в ЕЦП все спроектировано, задумано и внедрено удобно. Спорить с НЛМК в части ЕЦП не приходилось вообще OpenShift, Kafka, S3 всё на месте, всё как мы любим.

Учитывая, что и другие продукты уже начинали запускаться параллельно с нами, ЕЦП в НЛМК можно называть зрелой экосистемой. Ни одной значимой технической проблемы в проекте не было. Вместо этого, нас ждали организационные вызовы.

Аджайл VS реальность

Если признанные гуру аджайла спустятся с гор и увидят, как мы разрабатываем, их хватит удар. Оказалось, что ни одна из привычных практик не ложится на этот проект в неизменном виде. Уж очень сжатые сроки и большие масштабы.

Проект состоит из семи этапов, так что мы разбили работу на параллельные потоки:

1. тираж QR-кодирования сертификатов качества и готовой продукции на трех производственных площадках;

2. разработка сервиса для утверждения сертификатов качества электронной подписью;

3. разработка стартовых веб-страниц для экспортной продукции группы НЛМК;

4. разработка мобильного приложения для фотографирования транспортных средств и готовой продукции;

5. API для интеграции сервиса с информационными системами покупателей;

6. разработка тартовой страницы для предоставления информации по продукции, маркируемой DataMatrix-кодами;

7. разработка сервиса для автоматизации работы с несоответствиями готовой продукции (подача претензий по QR-кодам).

Фактически ребята ведут семь 7 потоков параллельно. Одну задачу разрабатывают, другую проектируют, третью выводят на демо, а по четвертой ждут результаты от зависимых систем, Ангелина Панарина, руководитель проекта, НЛМК-ИТ.

Вскоре стало ясно, что при таком количестве задач двухнедельных спринтов не хватает, чтобы довести макеты до релиза. Пришлось удлинить спринты до 3 недель.

Еще мы поняли, что не можем заранее утвердить проектную реализацию и сделать фиксированные спринты.

По одной из новых схем интеграций у нас не было готовых стандартов. Мы сделали предложения по интеграции, а через неделю поняли, что хотим все изменить. Ребята из КРОК отнеслись к этому лояльно, и все сделали. Зачастую, подрядчики отказываются делать внеплановые доработки, но в этом проекте мы находим компромиссы, потому что все ориентируются на результат, Михаил Скрипник, специалист направления производственных решений, НЛМК-ИТ.

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

Распределенная команда

Со стороны КРОК в проекте участвовало 11 человек. Ядро команды Группы НЛМК состояло из 24 IT специалистов. Получилась гибкая и разносторонняя команда, но постепенно в проект оказалось вовлечено больше 100 сотрудников из других подразделений НЛМК: эксперты от производства, интеграторы MES, инженеры, специалисты и руководители по продажам и начальники цехов.

Понадобилось около месяца, только чтобы разобраться, кто за что отвечает и какими знаниями обладает. Но сделать так, чтобы все они работали в одном таймлайне с основной командой оказалось практически невозможно.

Ачивмент: встать в шесть утра, чтобы зарядить разработчиков из Иркутска.

У техподдержки, например, на Урале свои: задачи, сроки и проблемы. Им приходилось одновременно участвовать в нескольких крупных проектах, решать текущие вопросы и поддерживать системы. Они оказались очень загружены.

Вы мне про аджайл, а мне оборудование настраивать надо, инженер Группы НЛМК, пожелавший остаться неизвестным.

Конечно, можно было форсировать работу через начальство, но так не добиться заинтересованности в результате, да и можно помешать другим проектам Группы НЛМК.

Мы поняли, что горизонтальные связи работают лучше. У нас была карта проекта список всех его участников по ролям. Аналитики и тестировщики звонили напрямую, погружали в проект и налаживали рабочий процесс индивидуально с каждым специалистом.

Пришлось смириться, что инженеры и сотрудники производства работают в другом ритме, за рамками спринта. Мы завели для них отдельный реестр поручений, регулярно обзванивали их, обновляли статусы задач и напоминали о сроках. Кстати, реестр показался бизнес-заказчику таким удобным, что он заглядывал туда чаще, чем в Jira.

Сложности коммуникации

Участники объединенной команды были разбросаны от Минска до Иркутска. Даже не будь пандемии, собраться вместе мы бы не смогли. Так что в начале проекта Skype-конференции стали основным каналом связи. Календарь состоял из непрерывных встреч и обсуждений. Времени на разработку не оставалось.

Когда собирается больше десяти человек из разных отделов (например, разработчики, управление сопровождения продаж, производство и контроль качества продукции), совещание затягивается и без дополнительных коллов уже не обойтись.

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

Теперь в коллах постоянно участвуют только менеджеры, техмены, аналитики и ведущие разработчики. Они передают задачи дальше, а остальные подключаются по мере необходимости. Благодаря этому большинство встреч не выходит за рамки регламента.

Итоги встреч мы фиксируем в письменном виде. Такие протоколы много раз выручали, когда информация забывалась или искажалась при передаче.

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

Вместо заключения

Нам удалось справиться с большинством организационных проблем и стать одной командой в течение полутора месяцев.

Для нас КРОК близкие друзья, мы учимся у них гибкости и неформальному подходу к решению задач, Ангелина Панарина, руководитель проекта, НЛМК-ИТ.

На старте мы бы и сами в это не поверили, но первый этап проекта, тираж QR-кодирования сертификатов качества и готовой продукции, был готов за четыре месяца. Мы запустили QR-кодирование на трех производственных площадках Группы НЛМК и заполнили стартовые страницы по огромному ассортименту продукции. Это позволило сократить расходы на обмен бумажными сертификатами, но основная цель этого проекта повышение качества клиентского сервиса.

Одни клиенты НЛМК уже пользуются сервисом и оценили его преимущества, другие пока знакомятся и разбираются, как наше решение упрощает их бизнес-процессы. Одним из следующих этапов развития QR-кодов будет полная интеграция с личным кабинетом клиента в онлайне, а также интеграция со складскими и учетными системами клиентов, Иван Говорухин, менеджер бизнес-решений, Группа НЛМК.

В ближайшем будущем клиенты Группы НЛМК на базе Единой Цифровой Платформы смогут мгновенно получать сертификаты качества, отслеживать поставки товаров, автоматически учитывать их при поступлении на склад при помощи API и быстро сообщать о дефектах продукции через личный кабинет на портале НЛМК.

Этот проект направлен на повышение удовлетворенности и создание максимально удобного сервиса для наших клиентов, партнеров и конечных потребителей продукции. Например, он позволяет нашим оптовым партнерам осуществлять упрощенную процедуру складского учета продукции, а также позволяет сделать прозрачным ее дальнейшую продажу, Борис Ашрафьян, начальник Управления Проектный офис, Группа НЛМК.

Это был непростой проект, но благодаря ему мы многое поняли. Если возьметесь за совместную разработку:

1. Выделите время на плавный старт

Как бы вы ни спешили, вряд ли сможете сразу выдавать реальные результаты. Первые две три недели участники объединенной команды будут притираться друг к другу. Лучше потратить это время, чтобы обследовать задачу и подготовиться.

2. Убедитесь, что все одинаково хорошо понимают цели и задачи проекта

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

Постарайтесь найти человека, который не понаслышке знаком с процессами, и регулярно консультируйтесь с ним. User story помогут вам докопаться до сути и сформировать общее понимание проекта. А еще лучше, если у вас будет возможность попасть на экскурсию по производству и увидеть работу компании собственными глазами.

Главное создать vision of future, когда все понимают, осязаемо понимают, что мы собираемся делать, Игорь Кораблев, энтерпрайз-архитектор, НЛМК.

3. Изучите команду

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

Важно, чтобы на старте проекта у вас было четкое понимание компетенций всех участников. Оно поможет распределить работу наиболее эффективно. В этом поможет контактная карта проекта.

4. Вовлекайте в совместную работу

Иногда в начале работы для участников объединенной команды неочевидна польза тесного сотрудничества. Ведь после окончания проекта они могут никогда не встретиться. Административным давлением эту проблему не решить. Приглашайте невовлеченных людей на совещания, зовите на демо, в главное общайтесь лично и открыто.

5. Доверяйте друг другу

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

Если это не касается каких-то внутренних ограничений информационной среды, нужно давать подрядчику творить так, как он считает нужным, Олег Богданов, куратор проекта, бизнес-заказчик, НЛМК.

Если согласование зашло в тупик, стоит обратиться за помощью к бизнес-заказчику. Ведь он больше всех заинтересован в результате проекта, и с ним проще договориться. Иногда это единственный способ сдвинуться с мертвой точки и продолжить работу.

6. Держите руку на пульсе

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

Неважно, будете вы использовать Jira, реестры поручений или другие подобные инструменты, для успеха проекта необходим жесткий контроль над распределением и выполнением задач. Руководитель проекта должен всегда понимать, какие поручения выполняют конкретные люди, когда наступают дедлайны и, особенно, почему они срываются.

7. Обучайте и обучайтесь

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

Мы научились ставить задачи друг другу и работать, как единое целое. Я вижу взаимный профессиональный рост разработчиков КРОК и НЛМК, Дмитрий Лаптев, технический менеджер, КРОК.

8. Создайте единое информационное пространство

Электронная почта не самый удобный канал для общения внутри команды, а групповые звонки часто затягиваются и отнимают массу времени.

Команде нужно общее пространство для асинхронного общения, где все видят сообщения, и не приходится повторять одно и то же по многу раз. Для нас таким хабом стал Confluence, выполняющий роль как хранилища проектных решений, так и мессенджера.

9. Не пытайтесь решить проблемы на 100%

Привычные подходы могут плохо работать в объединенной команде, но нет такого способа спланировать спринт, чтобы работа всегда шла гладко. Какую бы практику вы ни внедрили, она не даст 100% результат и не избавит разом от всех проблем.

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

P.S. Если у вас остались вопросы, можете написать на ipopkov@croc.ru.

Кстати, а вы работали в объединенных командах? Пожалуйста, поделитесь своим опытом в комментариях.

Успешность любого бизнес-проекта неразрывно связана с работой технической команды. В зависимости от масштаба проекта, его целей и особенностей, а также финансовых возможностей, компания выбирает наиболее удобную модель взаимодействия с ИТ-подрядчиком. В последнее время компании все чаще прибегают к внедрению в свои структуры специальной группы разработчиков через аутсорсинг.

Есть множество моделей взаимодействия, среди них можно выделить: фиксированная стоимость, время и материалы, фиксированное время и бюджет Но среди всех модель Выделенной команды значительно отличается.

Выделенная команда формируется исходя из целей, пожеланий и требований заказчика. Эта модель отлично подходит для разработки крупных долгосрочных проектов, в которых часто меняются требования. Она достаточно гибкая относительно объема работ и задач, затрат и ресурсов, а также относительно самой команды разработки.

Нанимая выделенную команду, вы, в некотором смысле, нанимаете слаженный организм, который вдохновлен вашими целями, следует вашим указаниям и не оставит вас на полпути к цели, если что-то пойдет не так.

Есть два аспекта в формировании выделенной команды. В первом случае команда представляет собой отдельную группу с полным обслуживанием, в которую входят все необходимые сотрудники, такие как руководитель проекта, дизайнер и т.д. В другом случае заказчик может нанять выделенную команду для расширения своей собственной, это усиливает его группу за счет нескольких внешних экспертов.

Причины, по которым стоит выбрать модель Выделенной команды:

1. Экономическая эффективность
Заказчики значительно экономят на инфраструктуре, поскольку, наняв команду, они получают почасовую оплату за удаленную работу над проектом. Отпадают такие заботы как аренда офиса, приобретение оборудования, оплата счетов за электроэнергию и т.д. Тем более гораздо дешевле нанять уже слаженную команду, нежели самостоятельно искать разработчиков с необходимыми навыками.

2. Хорошо подходит для крупных и сложных проектов
Эта модель полезна для проектов, в которых сложно все продумать до конца. Она достаточно гибка и может подстраиваться под любые изменения.

3. Доступ к ИТ-экспертизе
Когда вы нанимаете специализированную команду разработчиков, это позволяет компенсировать нехватку специалистов для реализации вашей уникальной бизнес-идеи. Вместе с тем вы получаете опыт экспертов, необходимые навыки, знания и ресурсную базу.

4. Высокая эффективность работы
Команда исполнителей глубоко понимает требования проекта, ориентирована на качество и работает на долгосрочной основе.

5. Прямое общение и мониторинг команды
Согласно данной модели клиент может напрямую управлять каждым специалистом, предоставленным ИТ-компанией.

6. Процесс разработки ПО контролируемый и управляемый
Заказчик участвует в процессе найма ИТ-специалистов, а также управляет процессом разработки на всех этапах, получая регулярные отчеты о выполненных задачах. При желании они могут поручить все работу по проекту аутсорсинговой компании, которая предоставила выделенную команду.

7. Гибкость в планировании и управлении изменениями
Заказчик на любом этапе может вносить изменения в проект, добавляя функции в программный продукт, а также распределять задачи среди исполнителей.

8. Масштабируемость команды
С самого начала заказчик самостоятельно решает, сколько человек нужно нанять для разработки ПО. При необходимости клиенты могут добавлять участников, а также уменьшать или увеличивать команду.

9. Прозрачная система ценообразования
Общая стоимость проекта формируется от поставленных задач и времени, необходимого для их выполнения. Каждый месяц клиент платит зарплату всем членам команды, а также поставщику услуг.

10. Самая надежная модель из всех
Это достигается за счет гибкости модели, прозрачности и 100% окупаемости наемной команды. Она позволяет избежать многих рисков, в том числе переплаты в процессе создания продукта.

Если вы сомневаетесь, стоит ли нанимать выделенную команду, то помните, вы инвестируете в будущее.

Как показывает опыт, преданные своему делу эксперты инициативны и решения, предлагаемые ими, могут удивлять.

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

Для будущих студентов курса "Product Manager IT-проектов" и всех интересующихся темой управления командой подготовили статью, автором которой является Сергей Колосков.

Также приглашаем всех желающих посмотреть открытый демо-урок Как продакт-менеджеру найти метрику роста и свести Unit-экономику?
За 1,5 часа на примерах реальных продуктов вы узнаете:
- почему успех продакт-менеджера это рост главной метрики продукта;
- как определить метрику роста;
- как построить аналитику и продукт вокруг метрики роста;
- научитесь расчету unit-экономики, как это делают продакт-менеджеры;
- узнаете, что может сделать продакт-менеджер для улучшения unit-экономики.

Те, кто работал с разными командами знают, что в одних командах что-то работает само, а в других за этим надо специально следить и организовывать. В одних все время появляются новые идеи, а в других надо организовывать мозговые штурмы или подкидывать материалы и спрашивать нашли ли что-то полезное.

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

Проблема 1: Много идей и разговоров, работа движется медленно

Вроде бы внутри команды все готовы к работе. Но все время что-то мешает, и есть куча недоделанных вещей. Например, все спроектировали и пишут код, но при этом Continuous Integration и контроль версий не работает. То, что из коробки есть сделали, а то, где надо докрутить почему-то не доделывается.

Диагноз: в команде нет людей на две роли:

• Специалист это профессионал, который любит и знает свою работу (например, пишет бэкенд или базу данных), но за свои границы не выходит. Continuous Integration для него должен делать кто-то другой.

• Лид. Особенно важен. Он нацелен на результат проекта и согласен для этого делать любую работу, которую нужно. Он понимает, что что-то он будет делать непрофессионально, тратить время, но на это тоже согласен.

Лечение: фокус на результате. Если такая ситуация возникает, а Работника в команде нет, нужен фокус на результате, особенно в серых зонах ответственности. Лучше всего организовать этот момент отдельно. И конечно, идеальный вариант найти Работника компании при формировании команды, и тогда этот фокус он организует сам.

Проблема 2: Ступор при проблемах и затруднениях

Ситуация, когда типичные задачи хорошо решаются, а в случае затруднений почему-то наступает ступор. Например, есть проблемы с производительностью в базе данных, ее все время оптимизируют, но результатов это не дает.

Диагноз: не хватает ролей, приносящих новые идеи. За них отвечают две роли Генератор и Исследователь ресурсов, и они совсем разные:

• Генератор активно порождает оригинальные идеи и видит самореализацию в их воплощении. Запилить какую-нибудь сложную систему фреймворка, декларативное описание форм, еще что-то, что не очень нужно, зато прикольно и красиво это про него.

• Исследователь не генерит идеи. Но он много читает, активно общается и приносит новые идеи из внешнего мира: новые технологии, которые хорошо бы применить.

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

Проблема 3: Бесконечные споры между конкурирующими идеями

Ситуация, когда существуют бесконечные споры между конкурирующими идеями. Как сделать общение фронтенда с бэкендом по разным паттернам. Или как использовать промежуточные транспортные Java-объекты: какими способами, какие нужны фреймворки и паттерны, использовать ли отдельно для каждого класса фабрику для порождения объектов или нет, и т.д.

Диагноз: в команде несколько конкурирующих Генераторов или Исследователей ресурсов, конкурирующих за реализацию своих идей. Два Генератора в команде такая же плохая идея, как и ни одного.

Лечение: развести Генераторов по зонам ответственности, или переключить одного из них в альтернативную роль, если она есть.

Проблема 4: Реализация сложных идей процесс, не результат

Бывает и так, что идеи есть, но они сложные. В этом случае команда либо не движется к результату, либо останавливается где-то на полпути. Это случается, когда есть мощный генератор, придумывающий новые сложные фреймворки и идеи, и которые сразу идут в реализацию. Но потом выясняется, например, что декларативное описание форм, которое он придумал, 100% проблем не решает, и даже 50% решает с трудом. Он его усложняет, но все кейсы и особые случаи все равно не натягиваются, и начинается ступор.

Диагноз: идеи от Генератора принимаются без рефлексии.

Лечение: организовать обсуждение и защиту идей до их реализации, а лучше заранее найти участника команды для оппонирования, чтобы оценивать идеи и варианты,

Проблема 5: Паралич принятия решений

Следующая проблема: есть несколько идей, а договориться по поводу того, какая из них станет рабочей, не удается. Возникает паралич принятия решений.

Диагноз: нет руководителей, нет таких, у которых есть роль, отвечающая за способность принимать решения.

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

Шейпер это более традиционный харизматичный руководитель, который активно и жестко ведет команду к принятым целям по выбранному им пути: Идем туда!

Лечение: внешнее руководство в точках принятия решений. Когда этот процесс налажен, неожиданностей почти не бывает.

Проблема 6: Слишком уверенный лидер

Диагноз: у руководителя-Шейпера нет уважаемого им оппонента Координатора для обсуждения решений. Это обратная сторона Шейпера без оппонента он ведет команду к поражению, а не к победе, но при этом уверен в правильности своих действий.

Лечение: создать внешние механизмы обратной связи для проверки курса движения команд, если нельзя найти оппонента в команде чтобы у Шейпера были оппоненты для проверки курса движения. Если вы знаете, что у команды харизматичный лидер и есть опасность, что он заведет не туда, то периодически его решения нужно проверять.

Проблема 7: Непродуктивная команда звезд

Симптомы: выдающиеся члены команды с высокой самооценкой не могут работать вместе и каждый тянет в свою сторону.

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

Диагноз: звезды в команде привыкли вести за собой и работать в роли руководителя, идеи которого без вопросов воплощаются в жизнь у них нет навыков и опыта совместной командной работы.

Лечение: Команде звезд нужен опытный руководитель-координатор, принимающий решения, потому что кто-то должен быть арбитром.

В такой команде существует парадокс: обычно руководитель команды умнее среднего участника, но не обязательно самый-самый (а вообще лучший вариант, если умнее других будет Генератор его задача подавать классные идеи, и пусть он не отвлекается на повседневное руководство). Но для команды звезд нужно, чтобы руководитель был глупее среднего уровня. Тогда звезды объединяются и сотрудничают между собой, чтобы донести до этого глупого руководителя свои гениальные идеи.

Проблема 8: Некому завершать работу

Симптомы: задачи приходят и остаются в состоянии почти все сделано, но функционал при этом нельзя использовать. Казалось бы, всё почти готово надо всего лишь тут и там завязать бантики. Но почему-то все они остаются не завязанными.

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

Педант (Completer Finisher) доводит дело до конца. Перфекционист, для которого главное качество и детали, а сроки могут подождать. Но без него оставшиеся 20% проекта никому не интересны.

У Педанта есть и обратная сторона он хочет сделать все излишне качественно. Если он стоит во главе команды, последствия ужасны, потому что для него сроки это ничто. Но если он не руководитель, у него все время голова болит о том, что еще не внедрено и недоделано.

Лечение: чек-листы и административный контроль за реальным завершением задач не нужны, когда педант есть в команде.

Проблема 9: Нет сотрудничества

Симптомы: поиск виновных в проблемах и неудачах, отсутствие взаимопомощи, люди указывают на несовершенства других.

Диагноз: нет человека, который бы заботился о взаимоотношениях и сглаживал острые углы, это слепая зона у руководителя. Оказывается, это отдельная роль. Это не Координатор, и тем более не Шейпер, то есть роль не должна быть руководящей.

Душа команды (Team Worker) ненавязчиво налаживает отношения в команде, сглаживает углы и не участвует явно в управлении.

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

Формирование команды с учетом знаний о проблемах

Момент 1: Пригодность и приемлемость

При составлении команд имеют значение как профессиональные знания и навыки, так и приемлемость по командному профилю (роли):

• Пригодные и приемлемые им работа скучна, это просто ступенька карьеры.

• Приемлемые и непригодные развиваются, и им интересно работать в команде.

• Неприемлемые, но пригодные проблемные. Работу делают, но в команде из-за них возникают трения.

• Непригодных и неприемлемых надо уволить из команды в другой команде они могут подойти по профилю и проявить свои сильные стороны.

• Для баланса должны быть все командные роли. Конечно, каждый может играть несколько ролей, переключаясь между ними.

При формировании команды:

• Нужны идеи, исполнители и организаторы.

• Нужен хотя бы один (а лучше несколько) Работников компании и желателен один Педант.

• На несколько ключевых ролей (ядро команды) выбирайте профессионалов (пригодных по знаниям и навыкам) и у которых нет резких конфликтов по ролям. Они обеспечат выполнение работы.

• Дополняйте команду пусть и не столь выдающимися специалистами, но приемлемыми по командному профилю. Даже если они имеют формально недостаточный уровень по знаниям и навыкам, они будут расти и эффективно работать.

• При включении новых людей в сложившуюся команду приемлемость критичнее, чем знания и навыки. Если новый сотрудник подходит по своей роли, это снизит шторминг после его появления в команде.

• Командный дух не обеспечивает успеха, а конфликт между Шейперами и Генераторами не стоит решать при помощи их примирения его надо делать конструктивным.

• Однородные команды слабы и часто выбирают себе подобных.

• Обязанности следует делить с учетом профессионализма и (обязательно!) ролей участников команды.

Момент 2: Состав сбалансированной команды:

• Руководитель Координатор, умеющий работать с талантливыми, но зачастую трудными участниками;

• Один сильный Генератор;

При этом хорошим будем следующее распределение умственных способностей:

• умный Генератор;

• еще один умный не-Генератор, который ему оппонирует;

• умный Координатор;

• остальные чуть ниже среднего уровня.

Момент 3: Размер команды

Оптимальный размер команды 5-7 человек:

• Ни 5, ни 7 человек не проигрывают и не выигрывают;

• 8 человек могут быть успешны, но возрастает нагрузка на руководителя, а также требования к нему;

• 4 человека могут быть успешны, если представлены все роли. Но в этом случае у команды нет резерва;

• В команде от 10 человек неизбежно появляется ядро из 2-4 человек, принимающих решения и люди без включения в него.

Момент 4: Команды-победительницы

• Смешанные сбалансированные команды, где представлены все роли.

• Однородные команды из стабильных экстравертов. В IT это редкость, но все же такие встречаются. Эти команды хорошо работают за счет сотрудничества, так как им нравится трудиться вместе. Роли в таких командах могут быть не выделены, но сотрудничество помогает преодолеть проблемы. Правда, они так же весело могут пойти на дно.

• Команды, во главе которых суперзвезда: если стратегия лидера верна, команда движется к победе, если нет к поражению. И то, и другое будет стремительным.

• Команды типа Аполлон (команды звезд): острый ум, ресурсы и таланты, но и большие сложности в их применении. Ключ к успеху хороший Координатор. Для сложных проектов такие команды особенно хороши, но нужно внимательно выбирать руководителя проекта.

Узнать подробнее о курсе "Product Manager IT-проектов"

Смотреть открытый демо-урок Как продакт-менеджеру найти метрику роста и свести Unit-экономику?

Честно сделанные ошибки следует считать не неудачами, а семенами для основной деятельности по их исправлению

Предисловие

Буквально несколько дней назад был "субботник" у одной компании с красно-белым лого. В первом докладе спикер рассказывал про оси развития разработчика. Всего он выделил три оси:

1. Технологии

2. Продукт

3. Люди

В целом, он не ошибся. Любой разработчик может уйти в сторону оси "Технологии" и делать свой стек технологий сильнее - становиться ведущим или старшим разработчиком. Можно попробовать прокачать себя в оси "Продукт" - уйти в PM и потом пойти дальше по матрице компетенций и расти по вертикали. Но есть еще одна ось, о которой можно много говорить, о которой много пишут, писали, и будут писать - "Люди". Управление людьми, работа с командой напрямую, выстраивание своих локальных процессов разработки - участь TeamLead (далее TL).

Я осмелился написать этот пост на основе своих же ошибок. Мне не стыдно их признать, не стыдно рассказать о них, показать, что некоторые тактики не всегда помогают.

Ошибки

Все их допускают, без них никуда. На основе ошибок можно понять слабые места, понять, что и где нужно исправить или убрать. Ошибки толкают нас к движению, к прогрессу.

Вот и я будучи TL в компании в первые месяцы допустил несколько больших ошибок.

Доверие

Ошибка, которую допускают, я думаю, многие TL, в том числе и я - отсутствие доверия к своей команде или к людям из команды.

Мысли а ля "Я могу сделать это лучше" первое время постоянно рядом, из-за этого получается, что вы перегружаете себя и, конечно же, не успеваете. Ведь помимо разработки у вас есть другие не менее важные задачи. Решение данного вопроса очень простое: нужно учиться доверять, оценивать людей не только по их личным, но и по их техническим характеристикам. Тогда будет намного легче. Возможно, вы перестанете быть звездой-гением-мысли-лучшим разработчиком среди всех разработчиков в компании, но вы будете хорошим TL, который умеет самое главное - доверять. От этого вам плюсик в карму от команды.

Оценка сроков

Другая не менее распространенная ошибка - Ошибка в оценке сроков

Иногда, на глобальном планировании на несколько спринтов вперед бизнес может сказать "Нам нужно это, это, и вот это - сможешь?".

Тут начинается игра "Кто хочет стать Багоделом", потому что чем больше вы возьмете на себя и свою команду, тем больше будет проблем потом. Проблемы будут появляться из-за:

1. Непредвиденных обстоятельств, блокирующих задач других людей или команд.

2. Сложности. То, что по заявлением должно делаться N часов - делается 2N часов - отсюда смещение по времени и нарушение дедлайнов.

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

В итоге, получается ситуация, где все можно успеть, но или очень с очень плохим качеством (т.е. техническим долгом), или с убитой командой, или (самый благоприятный исход) - просто не успеть.

Приоритеты

Это особенно важная история в рамках команд, которые работают над несколькими большими задачами в спринте.

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

Отсутствие развития сотрудников в профессиональном плане

Вы как TL должны думать не только о том, какие фичи поставляет ваша команда, но и том, как развивать каждого члена команды в отдельности. Ведь все абсолютно разные, у всех свой опыт и свой бэкграунд, а значит каждому нужна своя траектория развития.
Вряд ли разработчик будет сидеть на одних и тех же задачах - он потребует больше, интереснее, сложнее. Учитывая это, TL может построить правильную траекторию развития каждого разработчика.

Общение с разработчиками

Или One-to-One. Лучший способ узнать что происходит у разработчика - прямо спросить. И не обязательно спрашивать "ну что, как там с задачами?". Нужно быть человеком и искренне проявлять интерес к жизни сотрудника. Спросить что-то отвлеченное от работы или обсудить, к примеру, вчерашний футбольный матч - прекрасное начало диалога, который поможет больше понять что беспокоит сотрудника. Если необходимо спросить про трудности с задачами - это стоит делать без претензией, а с искренним желанием помочь.

Ошибок, которых я допустил - тысяча. Но скажу одно - даже у ошибок есть польза. Нужно просто уметь получать эту пользу.

Конфликты

Самое страшное, что может случиться в команде - это конфликт между разработчиками. Что самое забавное, его причины достаточно прозаичны, например - pull request был предвзято оценен или чрезмерно раскритикован. И самое неприятное в конфликте то, что он может быть продолжительным и он может съесть день вашего времени. Решение конфликта кроется в общении:

1. С каждым по-отдельности - разговор one-to-one для поиска причины и оценки ситуации

2. Совместно с конфликтующими - разговор, который направит на нахождение компромисса

Это поможет быть:

1. Ближе к команде

2. Справедливее. Вы не занимаете стороны - вы стремитесь к общей идее сплоченной команды

Не занимайте стороны, не говорите эмоциями - говорите фактами.

Заключение статьи

Сейчас, спустя несколько месяцев работы TL, я могу с уверенностью сказать, что многие вещи в команде стали лучше. И процессы разработки, и качество кода, и взаимоотношения с командой. И стали они лучше благодаря одной простой вещи - признанию своих ошибок.

Проблема производительности команды не кроется в отдельных разработчиках - она кроется в грамотной постановке не только дедлайна и задачи, но и в условиях, в которых разработчики каждый день находятся, в правильной "постановке атмосферы" разработки - надеюсь не перемудрил и вы меня поняли. Если кратко: сделать комфортные условия и увеличить КПД - вот задача тимлида.

В следующей статье я расскажу о других наблюдениях, или "очевидных открытиях". А пока спасибо за внимание и до скорых встреч. Жду ваши отзывы и предложения.

Как любая скрам-команда каждый день, мы стараемся быть лучше чем вчера. Мы делаем лучше наш продукт, мы вместе развиваемся как команда и, конечно же, мы растём личностно и профессионально. Очевидно, что одной лишь веры в то, что завтра мы станем быстрее/выше/сильнее не достаточно. Нужно понимание своих слабых и сильных сторон, а так же осознание того, что нам нужно здесь и сейчас, а что нам понадобится через неделю/месяц/год.

С точки зрения каждого члена команды, мы полагаем, что "каждый сам себе CEO", тем самым, это зона ответственности каждого индивида. С точки зрения продукта - у нас есть менеджмент, который собирает метрики, делится своим видением будущего и планирует дорожные карты. Но с точки зрения команды - у нас есть мы сами, продукт и нам со всем этим нужно что-то делать.

Я хочу поделиться с вами некоторыми инструментами, которые мы используем командой для обнаружения проблем на ранних стадиях, улучшения продукта и сохранения миролюбивой и уютной обстановки внутри.

Опросы

Да, это очередные опросы, но в нашем случае они приносят пользу и каждую ретроспективу поднимаем вопрос, нужны ли нам они или уже нет. У нас спринты длятся 2 недели, поэтому у нас есть еженедельный опрос и опрос в конце спринта.

Еженедельный опрос

В конце каждой недели мы получаем опросник на 30 секунд с вопросами: как часто у вас не было сил выполнять работу? Получал ли удовольствие от задачи? Сколько часов переработал? На выходе мы строим график для всей команды в динамике за последние 6 недель и обсуждаем на ретроспективе.

На таких графиках сразу становится понятно состояние команды, на сколько команда устала, как текущие задачи или краткосрочные приоритеты влияют на команду. Каждый член команды может сопоставить свои ответы с результатами команды. Например, если мне было тяжело, а по графикам я вижу что команда была в хорошем состоянии, то в следующий спринт я попробую забрать более интересные задачи себе, или брать поменьше задач. Или видно, что вся команда падает духом, тогда с владельцем продукта (PO) обсуждаем приоритеты следующего спринта и т.п. Как минимум, появляются аргументы для обсуждения.

Опрос в конце спринта

Тут всё просто, мы за пару часов до ретроспективы всей командой отвечаем на простой вопрос "Как вам спринт"? Тут мы уже преследуем цель разговорить команду. До введения этого опроса, ретроспектива начиналась с молчания и попыток скрам-мастера разговорить людей, что, как правило, заканчивалось "да обычный спринт, ничего такого". Сейчас же команда стала более разговорчивой, больше обсуждают проблем и кидают больше идей.

Опросы раздражают

Тем не менее, хоть мы и используем опросы, они раздражают, т.к. есть ещё опросы от компании, но более эффективных инструментов, работающих для команды вне офиса, мы пока не придумали. Может быть, кто-то в комментариях подскажет более эффективный способ, подходящей для удалённой работы. Однако, люди также отвечают на эти вопросы сами себе и тоже делают выводы.

Мотивация

Наша команда разрабатывает B2B продукт, известный только в узких кругах компаний, и новые члены команды столкнулись с тем, что им никто не объяснил кто и для чего используют наш продукт. В итоге это выглядело так: вот вы, вот продукт с кучей легаси кода, вот Jira - поехали.

Внутри команды мы собрали вопросы для менеджмента и попросили нам предоставить разные цифры. Например, список всех наших кастомеров, какой функционал чаще используется, приносит ли наш продукт прибыль и т.п.

Как минимум, воодушевление пришло когда люди узнали кастомеров, например, "О, это мой банк", "У этих 3-х компаний больше миллиона сотрудников", "У меня машина этой компании" или "Я читаю финансовые новости от них". Думаю, в компаниях, названия которых встречаются хотя бы раз в месяц дела обстоят лучше.

Боли (от выполнения ручной/неудобной работы)

Когда мы взяли новых членов команды, то от них услышали, что некоторые процессы сложные/долгие/непонятные. Возможно, ранее так казалось и другим, но со времени все привыкли/забили/смирились. Т.к. у нас появилась возможность выявить слабые стороны, мы решили ею воспользоваться. Для этого мы начали:

• Выслушивать и записывать недовольства всех членов команды. Про долгий билд, про QA автоматизацию, про непонимание того, на что нужно делать акцент в продукте и т.д.

• Сравнивать затреканое время в Jira между нашей командой и другими командами, чтобы понять, кто делает что-то лучше нас и почему мы не делаем также.

• Опять же посмотреть в Jira и рассмотреть что мы можем делать лишнего, или что уже не актуально и можно упразднить. Например, мы рассматривали релиз-тикеты и пытались понять какие моменты мы можем делать быстрее. Так мы обнаружили, что security scan кода занимал по 20-30 минут, мы подумали, что можно делать всё проще и в итоге сейчас это занимает около 5-10 минут.

На выходе у нас появились тикеты в существующих эпиках и новый эпик. В тот момент мы осознали, что для реализации некоторых тикетов могут понадобиться дополнительные скилы, которые ранее не использовались командой или случалось это крайней редко. А также пожелания от членов команды, кто и что хотел бы изучать.

В результате у нас всё задокументировано в Jira в эпиках (с чем мы уже можем прийти к PO для обсуждения включения этих улучшений в дорожную карту на следующий квартал), у нас уже есть правило, что 10% времени в спринте каждый тратит на развитие своих навыков, и у нас уже был план кто и что будет изучать. В нашей компании у всех есть доступ к обучающим курсам на разных площадках, поэтому вопрос самообучения был решён автоматически, но мы договорились о следующем:

• Изучение будет происходить в паре/тройке. Так и интересней, и если кто-то уйдёт в отпуск - работа не встанет.

• Пары/тройки будут меняться в будущем. Чтобы команда не дробилась на небольшие "кружки по интересам" и оставалась одной командой.

• Внутри пары/тройки нет ограничений на источник обучения. Кому-то могут нравиться курсы с LinkedIn, кому-то с Udemy, а кто-то вообще нашёл крутой разбор темы на YouTube на своём родном языке.

Больше болтовни

Иногда в офисе обсуждение небольшого вопроса у кулера может затянуться больше чем на пол часа и вовлечь несколько человек. Эти живые, неформальные беседы иногда вносят большой вклад в развитие команды и продукта. С уходом на удалёнку таких бесед почти не стало. А если ещё учесть что почти никто из нас ранее на удалёнке не работал - всем было очень трудно делить личное и рабочее время.

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

Также мы заметили, что когда люди включают web-камеру - они более искренне и более разговорчивы. Если вся команда не разговорчива, мы просто используем Wheel Of Names и там уже рандомом выбираем кто будет говорить.

Фидбеки

Фидбек - сам по себе очень крутой инструмент. Вы можете придумать крутую идею, внедрить её, не услышать фидбек и затем убрать её, т.к. можете считать, что она провалилась. Или наоборот, вы можете внедрить в процесс фигню, никто не будет говорить, что это плохо и в итоге эта фигня так и продолжит существовать. В общем, фидбеки - вещь классная.

Мы постоянно общаемся с менеджментом и PO и слышим от них статистику, на что стоит обратить внимание сейчас. Как правило, это запаздывающие метрики и в итоге часто мы тушим пожары, но редко уделяем много времени причине их возникновения, т.к. сразу переключаемся на другой пожар. Это не значит, что мы не проводим анализы причины, просто "предотвращать" пожары может стоить дороже, чем их многочисленное тушение.

Поэтому, мы стали искать те причины пожаров, решение которых займёт не много времени. Например, мы заметили, что наша L2 поддержка перегружена. Мы попросили фидбек от L2 команды и выяснили что у них много однотипных проблем от кастомеров, например, вот две из них:

• Кастомеры задавали вопросы на одни и те же сообщения в логе. Суть в том, что в логе мы печатали что-то вроде "Module: service XXX call, RC = Y, RSN = ZZ". Т.к. это вообще не понятно никому, L2 выстраивали у себя сводную таблицу таких сообщений, чтобы отвечать кастомерам. Если какая-то новая комбинация - то это шло дальше в L3 (к разработчикам). Решением было простым: мы просто написали функцию которая по кодам печатает user-friendly сообщения с полным описанием причины проблемы.

• Кастомеры находили уже пофикшенные баги. С каждым релизом мы не так много внимания уделяли описанию проблем. В итоге, когда пользователь встречал баг, он открывал описания выпущенных релизов и искал там свою проблему - разумеется он там ничего не находил и писал в саппорт. Ребятам из L2 приходилось лезть в нашу Jira и они пытались найти баги, похожие на кастомерские. Решение банально - мы стали лучше описывать баги с их симптомами в релизах. Кастомеры стали меньше писать в саппорт, т.к. находили свои баги в описаниях релизов, а если уж и открывалось, L2 на них почти всегда могли ответить самостоятельно и быстро.

В результате мы упростили работу нашей L2 поддержки. Но как это помогло нашей команде? У ребят из L2 появилось больше времени, и они тратили его на более глубокое изучение продукта, что позволяло отвечать самостоятельно на большую часть вопросов. Тем самым, количество обращений в саппорт уменьшилось, а также уменьшилось количество тикетов переходящих от L2 в L3. Тем самым, разработчики высвободили себе больше времени для решения реальных и актуальных проблем.

Ежедневный отчёт

У нас каждый день скрам-мастер, в конце рабочего дня, в канале команды в слаке публикует суточный отчёт, который описывает текущие горящие темы, блоки команд, проблемы в команде/продукте и т.п. Этот отчёт полезен как для команды, так и для менеджмента. Во-первых, если кто-то из команды имеет проблемы и видит, что его проблема там не описана - он идёт к скрам-мастеру и отчёт обновляется. Во-вторых, все видят что происходит сейчас в команде, у менеджмента есть актуальный, обобщённый отчёт, и им не нужно дёргать людей, чтобы получать ответы на свои вопросы. С помощью этого отчёта мы пытаемся добиться прозрачности и выявлять блоки как можно раньше, чтобы избегать случаев "У нас уже месяц всё хорошо, но 4 недели назад случилась проблема и мы не успеваем".

Я хочу ещё раз подчеркнуть, что этот "отчёт" - был создан внутри команды для нас самих же и не занимает больше 5 минут в день для его поддержания.

Свои метрики

Внутри команды у нас есть свои метрики. Некоторые пересекаются с менеджерскими, некоторые уникальны.

Например, кастомерские проблемы идут в приоритет и нам, как команде, очень важно, чтобы оно в L3 находилось как можно меньше времени. Поэтому мы стараемся отвечать на проблему, либо находить реальную причину (например, баг) как можно быстрее. Менеджмент всего лишь следит, чтобы ответ был не дольше чем за 2/7 дней (в зависимости от важности проблемы - у них свои метрики).

Частота "незапланированных" задач. Каждый спринт у нас случаются не запланированные таски, возникающие после старта спринта, которые откладывать на 1-2 недели нет возможности. Мы пытаемся отслеживать такие вещи, смотреть сколько в среднем мы тратим на них время и каждый спринт откусывать кусок пирога для этой активности. Тем самым, нам проще выполнять наши собственные коммитменты и тогда команда становится более предсказуемой.

Мы используем и другие метрики, включая самые очевидные: процент покрытия кода юнит-тестами, покрытие QA тестами функционала продукта, время жизни пулл-ревквеста или velocity команды.

Больше правил

Никто не любит правила, особенно никто не любит появления новых рамок. Однако, внутри команды правила могут помочь избежать конфликтов, или использоваться как аргументы в них.

Можно долго спорить и ругаться, например, что лучше: табы или пробелы, можно назначать митинги для их обсуждения, создавать новые чаты, ругаться в пулл-реквестах, а можно просто написать правило "только пробелы" и просто следовать ему. Кто-то будет недоволен, но теперь это правило, и его не обсуждают, ему просто следуют. Поэтому, рекомендую задокументировать всё, что связано с правилами написания кода. А ещё лучше, посоветовать команде почитать какой-нибудь Code Complete, чтобы разработчики (особенно начинающие) имели представление откуда эти правила берутся.

Правила помогают разделять белое и чёрное, избегать конфликтов и иногда упрощать жизнь. А иногда, наоборот, усложняют жизнь. Ввод любого нового правила означает снижение доверия к индивидуумам, снижение доверия означает рост неэффективности, рост неэффективности приводит к увеличению времени разработки.

Также, правила должны подвергаться пересмотру. Например, в какой-то момент времени у нас случилось несколько кастомерских проблем из-за релиза, баги в котором могли быть замечены аж на трёх этапах: Разработка (code review), Просмотр билда разработчиками, и уже QA. На всех трёх этапах можно было предотвратить ошибку. Разумеется, после этого инцидента все этапы были ужесточены. В итоге то, что раньше могло занимать до 5 дней, стало занимать до 10 дней. Со временем все ужесточения были пересмотрены. Некоторые до сих пор остались, просто был изменён процесс чтобы действие занимало меньше времени, что-то было упразднено, а что-то наоборот добавилось.

Правила - как инструмент, может нести и пользу, и вред. Иногда удобно вводить временные правила, чтобы решить текущую проблему, а иногда нужно осознано вводить правило в ущерб краткосрочным целям в пользу долгосрочных. Например, сейчас для любого изменения в коде у нас требуется минимум 2 апрува. Т.е. как минимум трое из пяти членов команды согласны на эти изменения.

Ответственность на всех

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

• Плохие вещи случаются. Нельзя запланировать и предвидеть всё.

• Если кто-то ошибся и это привело к последствиям, то это всего лишь значит, что человек был один, или процесс не так уж и хорош, как мы его выстраивали.

• Очень просто спихнуть всю ответственность на кого-то одного и осудить его. Если такое происходит часто, то все понимают, что рано или поздно это случится с ними и уходит доверие, что приводит к росту издержек, снижению эффективности ... ну вы поняли.

• Обвинения не решают проблем. Вообще никаких.

Яркий пример логики, где виноваты все: когда машина с автопилотом сбила переходящую через дорогу женщину с велосипедом в темное время суток. Кого винить?

• Женщину, которая в полной темноте переходила дорогу в неположенном месте?

• Водителя автомобиля с автопилотом, который вряд ли сам среагировал бы?

• Компанию, которая разрабатывает автопилот?

• Разработчиков, кто писал код для автопилота?

• QA кто выпустил этот код в прод?

Субъективно, тут виноваты все, либо никто. Но, очевидно, что виновные есть, т.к. в итоге женщина скончалась. Значит виноваты все.

Данный подход может показаться не справедливым, т.к. обвиняя всю команду вы обвиняете и каждого её члена, даже тех кто вообще никакого отношения к инциденту не имел. Но с другой стороны, переживать такого рода стресс всем вместе проще, чем одному, это также увеличивает вовлечённость всей команды в процесс и жизнь продукта, а ещё, справедливости не существует. Аналогично, когда хвалят всю команду - значит хвалят и каждого в отдельности. А похвалу любят все.

Team Building

Я не хочу заострять внимание на тимбилдинге, все мы понимаем зачем он нужен и каждый в этом участвовал. Тимбилдинг, так или иначе, нужен, особенно когда в команде появляются новые люди. Хочу отметить, что сейчас онлайн тимбилдингов уже существует много и есть где разгуляться. Основной посыл здесь, что не стоит ждать пока менеджмент соберёт всех вместе где-нибудь на очередной ежегодной вылазке. Нужно самоорганизовываться самим и организацию таких мероприятий (онлайн или оффлайн) брать на себя скрам-мастеру, тимлиду или самовыдвиженцам из команды.

Заключение

Выбрав фреймворк как Scrum, Kanban, Lean и т.д. глупо надеяться что все проблемы разрешатся, все будут мотивированы, счастливы и довольны. Внутри команды не стоит надеяться, что кто-то другой решит ваши проблемы, особенно, если вы о них не говорите.

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

Эта история личное мнение, основанное на наблюдениях, во время работы в разных проектах.

Вход в командную разработку

Во времена моей работы на фрилансе проблем по выбору стека технологий не было, все было просто, я советовался с друзьями, читал различные источники и выбирал нужный стек. Это были популярные вещи, потому что по ним было больше информации, больше готовых проектов, где можно было подсмотреть нужное решение и больше ответов на Stack Overflow, если сталкивался с какой-либо проблемой. Благодаря этому работать было не так уж напряженно.

Но когда я началработать в команде, выбор стека превратился в загадку. В голове постоянно крутилось: Зачем? Почему? Откуда это взяли? Что за подход? Я не понимал, почему в одной команде одни технологии, в другой другие, хотя все по сути делали одно и тоже.

Так же было очень интересно и не понятно, почему одни люди на проекте с пеной у рта доказывали превосходство выбранного пути, а в другой команде другие делали тоже самое, но по-другому и различные подходы в технологиях, которые я описывал из предыдущей команды попросту высмеивали.

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

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

Понимание происходящего

Начать наверно нужно с понимания, что истины не существует и каждый волен делать то, что ему захочется, лишь бы это не вредило общему процессу и результату. Учитывая, что на фронте +10 решений для любой проблемы.

Работа начинается с выбора базового стека, какой бы он там ни был, но дальше начинается большой потенциал для различных вариаций. Так же прибавляется уже существующая база написанного кода, ибо многие вещи или если сказать не все, уже написаны и их осталось только адаптировать под свои нужды.

Когда проект вступает в фазу стартапа тут все открыто и прозрачно. Ну понятно, нужно хоть что-то, как-то сделать. А после становления в проект начинают запихиваться дополнительные фичи и подключаться дополнительные модули.

Так же что бы понять происходящее, нужно обратиться к опыту участников проекта. Даже если он выше среднего, то на начальном этапе люди стараются придерживаться каких-то рамок и не особо блистать своим великолепным умом.

На следующей фазе, становится немного по веселее, рамки приличия постепенно стираются и в коде появляются какие-то супер технологичные подходы, паттерны и космические обертки возвращающие монады. И все это называется эффективным архитектурным решением, что по факту является набором диких самописных костылей, которые замыленным взглядом бывалых участников, смотрятся очень даже ничего, и просто вызывают панику и недоумение у новичков пришедших на проект.

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

Здесь становится просто скучно следовать стандартному технологическому флоу. Хочется больше треша, глубоко записанного в код проекта. Все чаще тимлида посещают мысли, что слишком просто писать на JS или легком TS. Нужна строгая типизация, нужен строгий анализатор кода. А то же может прийти новичок на проект и О Боже! совершить смертный грех, случайно пробросить в компонент не нужные пропсы, которые в нем быть не должны или вызвать не подходящую функцию. Все чаще он задумывается об ограничениях стандартных модулей, аля React Router. Как же можно пользоваться этим ограничивающим волю не доработанным роутером, который не дает доступ к history не в рамках React. А если спросить: А где тебе нужен будет доступ к history в твоем spa, не в рамках компонентов React? Будет ответ что-то вроде, что ты ничего не понимаешь в технологиях, и не можешь думать так же глубоко и на веки вперед.

Отношение руководства

В отношение руководства все проходит гладко. У менеджеров и своих управленческих дел предостаточно, чтобы вникать во всякие технологические изыски. И полагаясь на старшего разработчика, который бьёт себя в грудь, с абсолютной уверенностью и горящими глазами заявляя, что он так уже 100 раз делал, что проект выстрелит в 100 раз быстрее и надёжнее, что наступит мир во всем мире и полная идиллия, дает отмашку на внедрение супер архитектуры. Но их тоже нужно понять, они хотят, как лучше и если будет прирост производительности, почему бы и нет?

Go ahead

Выбор нового стека всегда проходит на коленке. Как правило делается беглый обзор, основанный на отзывах и звездочках на gitHubе. Wow Rust, Wow React-Reason. Это наш выбор!

Пишется для примера парочка компонентов, которые супер быстрые. Ну как же, они же компилятся в прекрасный человек читаемый код и очень производительны. Разработчик бы так не написал красиво, как интерпретатор. А дальше понеслась работа по перепилу всего приложения на новую архитектуру, которая практически всегда заканчивается вилкой приводящей к одному итогу.

1 вариант. После N месяцев разработчики сталкиваются с не разрешимыми проблемами, из-за которых приложение начинает тормозить еще сильнее, чем до переезда.

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

Итог

В какой-то момент, великий предводитель проекта, ведущий в светлое будущие, модными прорывными технологиями, понимает точку невозврата и проходит со словами: Мне тут что-то ценник x1,5 предложили, а мне сейчас деньги нужны, ипотека, кредиты и все такое. Ну в общем, не поминайте лихом, я пошел.

На вопрос удивленного руководства: А как же супер архитектура? Он говорит: Не довелось.

И здесь можно сделать ремарку, что человек то он действительно умный и продвинутый и начитанный, что делает его ценным специалистом и любая галера возьмет такого с руками и ногами, даже дороже рынка. Но вот цена этого ума, загубленный проект и команда оставшаяся не в лучшем положении.

И скорее всего такой ошибки он больше не совершит и будет придерживаться стандартного стека при разработке.

А руководство после ухода предводителя зайдет на hh.ru вобьет в поиск Rust или Reason получает гордый 0. И на радость команды вернется к разработке в свой старый добрый, понятный репозиторий.

Вывод из всей этой истории можно сказать такой, все модные технологии хорошо подходят для расширения кругозора разработчика и для поднятия скилов. Но пока на них не появится больших, сложных, работающих проектов, разработанных мудрыми разработчиками, наверно не стоило бы самостоятельно внедрять всю эту Моду в продакшн.

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

Это третья статья из цикла возможных ошибок, которые могут допустить разработчики в начале своей карьеры. Из этого следует, что сейчас я буду рассуждать о том, почему такое решение может обернуться проблемой в будущем.

Disclaimer: эта статья не является абсолютным правилом, и ваш опыт может отличаться.

Давайте для начала определим исходные условия для появления проблемы, которую я опишу чуть ниже.

1. Это ваше первое местое работы

2. Вы работаете там достаточно продолжительное время (1 - 1,5 года +)

3. Вы работаете с одним и тем же лидом/ментором

4. Вы работаете на одном и том же проекте с одинаковым стеком

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

В чем же суть проблемы, спросите вы? Первая работа и опытный ментор имеют крайне сильное влияние на человека. У вас нет времени оценивать каждое требование, нет каких-либо особых предпочтений, вы полностью доверяете старшему разработчику и это нормально. В какой-то момент вы так привыкаете к каким-то правилам (или отсутствию правил), что весь процесс работы над задачей проходит автоматически.

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

Но если мы принимаем как факт, что все-таки первый лид был достаточно опытным, то где же кроется проблема? И ответ на этот вопрос - в гибкости. Возможно сейчас кто-то со мной поспорит, но нет плохой архитектуры и плохих правил как таковых. Есть не рекомендуемые конструкции, но это не делает их плохими. Опытный человек понимает, где это не принесет больших проблем, а где стоит все-таки потратить больше времени и продумать удобную, расширяемую архитектуру.

Но есть гораздо более важный момент, вы работаете в команде, а самая лучшая команда - это та, которая пишет как один человек. В таком случае задача может легко перейти другому разработчику, а когда тебе поступает новая, ты можешь легко разобраться, что происходит в участке кода, который писал не ты. Также в каждой команде принят стандартный workflow для задачи, включающий в себя даже такие этапы, как именование веток или названия коммитов.

И workflow хорош именно тем, что он гибкий. Он изменяется под нужды текущей команды, проекта, релизов, постановки задач. То есть нет такого единого стандартного решения, есть база, которая видоизменяется со временем.

Если вы еще не поняли, как выражается эта проблема, то более конкретно - в непринятии новых правил, требований, стека. На автомате человек делает как раньше, не понимая потом, почему его задачу не принимают и просят переделать. Ему может показаться, что к нему придираются и просят изменить что-то малозначительное, хотя если смотреть шире - то можно увидеть, что это может быть давно принятым правилом, и команде так удобнее.

Смена работы - это часто стресс. Особенно в IT, где от команды к команде может измениться все. Когда ты долго работаешь на одном месте и уходишь в другое, то довольно тяжело принять что твое понятие хорошо, здесь может быть вообще не хорошо. Или наоборот, то что ты считал плохим решением, здесь используется повсеместно. Самое главное - понять на этом этапе, что такое возникает не потому что в другой команде делают неправильно, а что они приняли такой вариант, потому что им было удобно с этим работать в данный момент времени.

В дальнейшем будут приводиться примеры, они взяты из личного опыта. Примеры необходимы для иллюстрации, как это происходит на практике с объяснением почему в данном проекте и команде было принято так, или почему вот так не сделали. Ни в коем случае они не сделаны, для того чтобы показать, что люди чего-то не понимали или были не правы.

Иногда проблема возникает из-за незнания по какой причине было принято определенное правило или использовалась какая-то библиотека в силу неопытности. Неосознанно, чтобы уменьшить "незнакомость" проекта и вернуться во что-то привычное, человек может начать продвигать технологии, которые использовались на прошлом месте работы. Иногда эти предложения могут быть серьезными усложнениями, не дающими в перспективе значительных улучшений в качестве и простоте кода.

До этого я приводила примеры и описывала ситуации, которые возникают с людьми, которые работали с опытными менторами. Но все-таки стоит затронуть ситуацию с низкими стандартами кода, которая иногда встречается в тех же веб-студиях. Если в прошлых примерах разговор чаще шел о хороших практиках, которые просто не подходят под текущую ситуацию и стиль команды, то с людьми из следующих примеров чаще обратная проблема. Им наоборот кажется, что все правила - это усложнения и зачем заморачиваться, если и так все работает.

Бывает, что они могут отнестись с негативом к изменениям их кода в пользу более удобной архитектуры, которая рассчитана на дальнейшие изменения. Также может быть негатив к линтерам и форматтерам, если они с ним не работали, их могут раздражать эти "ошибки", которые они не считают ошибками, а своим стилем. Но как я уже объясняла выше, важно, чтобы команда писала как один человек, поэтому их задачи будут продолжать откатываться, чтобы привести все к единому стандарту.

Кстати именно из-за этого в вакансиях на разработчиков может присутствовать строчка от n лет коммерческой разработки, не всегда у команды есть время ждать, пока новый сотрудник привыкнет к высоким стандартам, и более простым решением становится нанять того, кто на практике уже к этому привык.

Немного о фрилансе

Если человек долго работает в фрилансе, у него также могут возникнуть проблемы, когда он начинает работать в команде. Кстати по той же причине, что и у людей, еще не менявших до этого работу. Иногда у людей во фрилансе нет понимания, что при работе в команде ты не один показываешь результат, а вся команда, и оценивают ее в целом, а не кого-то отдельного. Соответственно, гораздо более приоритетен результат и продуктивность всех в общем, а не конкретно взятого сотрудника.

Заключение

Проблему я описала, а решение нет. Если вы впринципе не хотите столкнуться с этой проблемой, то это абсолютно нормально сменить несколько мест работы (только не через 3 месяца, пожалуйста), даже при условии, что на текущей вас все устраивает. В начале карьеры вы максимально гибки, и вам будет легче адаптироваться, в дальнейшем в этом уже нет необходимости, так как приходит понимание, почему важно придерживаться определенных правил и где стоит гнуть свою линию, а где важнее командная продуктивность.

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

Если же вы недавно сменили и столкнулись с непринятием и негативом из-за новых правил, то постарайтесь оценить объективно, не является ли это стремлением к тому, чтобы вернуться в старые знакомые края, и действительно ли то, что вы считаете правильным, будет являться правильным для всей команды? Если вы считаете, что да, то постарайтесь аргументированно доказать свою точку зрения с практическими примерами, но также учтите сроки и пользу таких изменений и являются ли эти 2 метрики соразмерными.

Вообще в этой статье я также хотела поговорить о навыке релиза продуктов, но текста уже достаточно много, так что я поговорю об этом в следующий раз.