Русский
Русский
English
Статистика
Реклама

Процессы в it

Организация рабочего процесса в команде на IT проекте

21.10.2020 14:12:03 | Автор: admin
Привет друзья.

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

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

В свое время я как раз и попал на такой проект, где были все эти прелести.

Никто не хотел брать на себя ответственность за проект (большой сервисный маркетплейс), текучка была страшная, заказчик просто рвал и метал. СЕО как-то подошел ко мне и сказал, что ты имеешь нужный опыт так вот тебе и карты в руки. Забирай проект себе. Облажаешься, проект закроем и всех выгоним. Получится, будет круто, тогда веди его и развивай, как считаешь нужным. В итоге я стал тимлидом на проекте и все легло на мои плечи.

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

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

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

Поскольку на моем проекте это работает, то может быть кому-то это также сможет помочь. Итак, сам процесс, который помог нам спасти проект:

Процесс работы команды на проекте Мой любимый проект


a) Внутри командный процесс (между разработчиками)

Все задачи создаются в системе Jira

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

Любая фича, если она достаточно сложная, разбивается на много мелких тасок

Команда работает над фичами, как единой таской. Вначале делаем все вместе одну фичу, отдаем ее на тестирование, затем берем следующую.

Каждая задача маркируется, для бэкенда или фронтенда она

Есть типы тасок и багов. Нужно верно их указывать.

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

Тот кто выполнял задачу сразу же трекает свое время для этой задачи

После проверки кода, ПР апрувится и после этого, тот, кто выполнял эту задачу, самостоятельно мержит ее в мастер ветку, после чего изменяет ее статус в готова для деплоя на дев сервер.

Все задачи, готовые к деплою на дев сервер, деплоятся тимлидом (его зона ответственности), иногда членом команды, если что-то срочное. После деплоя все таски с готова к деплою на дев переводятся в статус готова к тестированию на деве

Все задачи тестирует заказчик

Когда заказчик протестировал задачу на деве, он переводит ее в статус готова для деплоя на прод

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

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

В итоге все задачи проходят путь от создания до завершения: To Do In Development Code Review Ready deploy to dev QA on dev (Return to dev) Ready deploy to prod QA on prod Done

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

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

Разработчики в первую очередь выполняют приоритетные задачи.

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

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

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

Каждый день в одно и то же время (у нас это в 12.00) мы проводим митинг между всеми членами команды

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

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

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

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

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

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

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

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

Рабочий процесс происходит по скраму. Все разбито на спринты. Каждый спринт длится две недели.

Спринты создает, наполняет и закрывает тимлид.

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


б) Процесс работы с заказчиком

Каждый разработчик может и должен коммуницировать с заказчиком

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

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

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

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

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

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

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

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

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

Перед тем, как взять в работу любую задачу, мы должны удостоверится, что эта фича входила в условия нашего договора/контракта. Если это новая фича, которая выходит за пределы наших первоначальных договоренностей, то мы обязательно должны заэстимейтить эту фичу ((примерное время выполнения + 30%) х 2) и указать заказчику, что у нас уйдет столько-то времени на нее, плюс дедлайн смещается на время эстимейта помноженное на два. Сделаем задачу быстрее замечательно, все от этого только выиграют. Если нет, то мы подстраховались.

в) Что мы не приемлем в команде:

Необязательность, несобранность, забывчивость

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

Бровады и похвальбы от человека, который не доказал еще делом свои возможности и профессионализм. Если доказал, то можно, в рамках приличия :)

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

Когда специалист все время в офлайне и к нему сложно достучаться в рабочее время.

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

________________________________________________________________________________

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

1. Какие у вас критерии качества?
2. Как вы определяете есть ли в проекте проблемы или нет?
3. Нарушая все наши рекомендации и советы по изменению/улучшению системы, все риски несете только вы
4. Любые мажорные изменения проекта (например, всевозможные экста флоу) будут приводить к возможному появлению багов (которые мы будем, естественно, фиксить)
5. Невозможно в течении пары минут понять, что за проблема произошла на проекте, а тем более тут же ее пофиксить
6. Мы работаем по конкретному продукт флоу (Таски в Жира Разработка Тестирование Деплой ). А значит мы не может реагировать на весь поток просьб и жалоб в чате
7. Программисты являются именно программистами, а не профессиональными тэстировщиками, и не могут обеспечить надлежащее качество тестирования проекта
8. Ответственность за конечное тестирование и прием задач на проде лежит полностью на вас
9. Если мы уже взяли в работу задачу, то не можем сразу же переключаться на другие, пока не доделаем текущую (иначе это приводит к еще большим багам и увеличению времени разработки)
10. Людей в команде стало меньше (по причине отпусков или болезней), а работы стало больше и мы физически не успеем реагировать на все, что вы хотите
11. Просьба с вашей стороны сделать деплой на прод без протестированных задач на деве это только ваши риски, а не разработчиков
12. Когда вы ставите нечеткие задачи, без корректного флоу, без макетов дизайна, то это требуюет от нас намного больших усилий и сроков реализации, так как нам вместо вас приходиться делать дополнительный объем работы
13. Любые таски по багам, без детального описания их возникновения и скриншотов, не дают нам возможности понять, что пошло не так, и как нам сэмитировать этот баг
14. Проект требует постоянной доработки и улучшений для повышения производительности и безопасности. Поэтому команда тратит часть своего времени на эти улучшения
15. По причине того, что у нас бывают переработки по часам (срочные фиксы), то мы должны их компенсировать в другие дни

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

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

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

Исходник в моем блоге: https://cleverman.org/post/organizaciya-rabochego-processa-v-komande-na-it-proekte
Подробнее..

7 soft skills, которые нужно начинать прокачивать уже сейчас

22.10.2020 12:07:47 | Автор: admin
image

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

Я Анастасия Горелова, руководитель программ обучения Хаб Знаний МойОфис. Занимаюсь проектированием и реализацией программ развития hard и soft skills наших сотрудников, обучаю коллег, партнеров и клиентов работе с продуктами МойОфис, а также продвигаю наши образовательные проекты в школах и университетах.

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

1. Комплексное решение проблем


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

image

Пример: среди требований к новой почтовой системе Mailion, которую создают разработчики МойОфис, есть отказоустойчивость и самовосстанавливаемость. Поскольку решение устанавливается на инфраструктуре клиента, мы не сможем иметь к нему доступ. Поэтому коллеги постоянно совершенствуют работу системы, чтобы в случае отказа она сама смогла быстро восстановиться. Ситуаций может быть множество, важно заранее предусмотреть все случаи, а это не так уж и просто.

Вопрос для самопроверки:

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

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

2. Умение убеждать


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

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

Вопросы для самопроверки:

  • Замечали ли вы, что вас перебивают на совещаниях? Было ли ощущение, что вас никто не слушает?
  • Стараетесь ли вы приводить наглядные кейсы, когда отстаиваете свою точку зрения?
  • Как вы начнете рассказ о себе? Отрепетируйте небольшой спич.
  • Вспомните случай, когда после разговора с вами коллега менял свое мнение. Что именно помогло вам переубедить его?
  • Как вы реагируете на возражения?

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

3. Навыки сотрудничества и работы в команде


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

image

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

Вопросы для самопроверки:

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

Для развития навыков сотрудничества в некоторых командах мы практикуем метод ротации, когда разработчик из одного проекта МойОфис на время переходит в смежный. Это не только позволяет попробовать себя в новом деле, но и прокачивает умение общаться с коллегами, помогает не закисать и переключаться с рутинной работы на новые задачи. Если есть запрос, мы организовываем специализированные курсы для развития личных и профессиональных навыков. Кроме того, всем нашим руководителям мы настоятельно рекомендуем на регулярной основе проводить one to one встречи с каждым членом команды, чтобы участники могли скорректировать планы, задачи, выстроить доверительное общение и на ранних этапах предугадать появление ошибок. На таких встречах сотрудник учится задавать правильные вопросы, слышать обратную связь, осваивает навыки конструктивно обсуждать взаимодействие в команде.

4. Умение планировать свою работу


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

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

Вопросы для самопроверки:

  • Вас просят назвать сроки готовности проекта. Чем вы будете руководствоваться при оценке?
  • Разгар рабочего дня, и вдруг коллега присылает вам ссылку. Вы знаете, что там полезная и важная статья. Как вы поступите?
  • Составляете ли вы рабочие и личные планы на день/неделю/месяц? Как много из них удается выполнить?
  • Знаком ли вам метод планирования времени матрица Эйзенхауэра?
  • Знаете ли вы, сколько времени у вас в среднем уходит на каждый тип задач?
  • Сколько минут / часов в день вы проводите в социальных сетях? Отслеживаете ли вы каким-либо образом эту статистику? Используете ли тайм-трекеры?
  • Практикуете ли отдых от соцсетей и интернета, digital detox?

Для планирования работ и фиксации промежуточных вех проекта некоторые отделы МойОфис используют методологию Scrum и обучают ей новых сотрудников, чтобы группа работала слаженно. Часть команды в Москве ориентирована на освоение стандартных методик управления проектами по методологии PMI PMBoK. Мы в Хабе Знаний в свою очередь пополняем библиотеку компании материалами по тайм-менеджменту коллегам доступны актуальные новинки, техники из которых они могут начать внедрять сразу после прочтения.

5. Критическое мышление


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

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

Вопросы для самопроверки:

  • Задумываетесь ли вы при чтении материалов в интернете о том, кто и с какой целью их публикует?
  • Как вы определяете, какой информации можно доверять? На какие критерии вы опираетесь при выборе источников информации?
  • Проверяете ли вы адреса сайтов и защищенность соединения при переходе по незнакомым ссылкам?
  • Есть ли у вас список доверенных источников информации?

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

6. Постоянное обучение long life learning


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

image

Пример: хотя Java и C# уже несколько лет занимают значительную часть рынка, IT-компании все чаще используют более новые технологии (Kotlin, Swift и др). И логично, что разработчики, хорошо владеющие несколькими языками, дадут фору тем, кто знаком с одной-двумя технологиями. Через пять лет наверняка появятся новые стеки, поэтому чтобы оставаться востребованным, важно постоянно учиться и уметь выбирать подходящий инструмент для решения конкретной задачи, основываясь на комплексном анализе факторов.

Вопросы для самопроверки:

  • Участвуете ли вы в развитии open-source проектов? Сколько коммитов вы сделали за прошедший год? Сколько создали багов и предложений в трекере? На сколько вопросов ответили?
  • Как давно вы изучали незнакомую для себя технологию?
  • Как вы поступите, если узнаете о появлении нового языка, который набирает популярность?
  • Как вы реагируете, если вам предлагают пойти на обучающее мероприятие?
  • Какие профессиональные конференции вы посещаете?
  • Чему вы научились в вашей профессиональной области за последние полгода?

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

7. Соблюдение work-life balance


Cоблюдение work-life balance и ваше самочувствие прямо влияют на продуктивность: тот, кто заботится о себе, обычно живет дольше, работает эффективнее и успевает уделять должное внимание другим важным делам. Тема здоровья тесно связана со всеми сферами жизни, в том числе с работой. Не буду ничего говорить про биохакинг и вживление чипов под кожу (это тема отдельного поста а то и не одного), этот пункт больше про внимание к телу, к психоэмоциональному состоянию, а еще о том, что разделение личной и профессиональной жизни помогает им взаимно друг друга поддерживать. Старайтесь быть терпимее к другим, особенно если их точка зрения противоречит вашей, выражайте чувства без вреда окружающим и осознавайте, на что вы можете повлиять, а на что нет. Найдите хобби по душе и помните, что от того, как организована ваша жизнь после работы и учебы, будут отчасти зависеть и карьерные успехи.

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

Вопросы для самопроверки:

  • Когда вы последний раз проходили комплексное обследование?
  • Что вы делаете для того, чтобы ваше питание было сбалансированным?
  • Сколько часов в сутки вы спите? Высыпаетесь ли вы? Если нет, что вы можете сделать уже сейчас для улучшения качества вашего сна?
  • Утром вы чувствуете себя простывшим, но нужно ехать на работу. Как вы поступите?
  • Работаете ли вы в отпуске? Доделываете ли проекты в выходные? Пишете ли в рабочие чаты по вечерам?
  • Какие у вас хобби? Давно ли вы увлекались чем-то для себя новым?

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

Вместо послесловия


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

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

Фронт без релиз-инженера, или Как я перестал бояться и полюбил деплой

08.02.2021 14:10:06 | Автор: admin

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

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

  • Разделение ответственности в ряде случаев ответственность за деплой оказывается высокой.

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

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

Как это происходит у нас

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

Немного истории

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

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

Да придет спаситель

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

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

И, кажется, коллеги со мной согласны:

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

Схема связи Шамана с кодом

На данный момент почти все наши GitHub-репозитории собираются при помощи GitHub Actions, в результате чего докер-образ пушится в общую приватную докер-репу. Этот workflow можно триггерить как автоматически (пуш в релизную ветку), так и руками, если хочется потестить какой-то сиюминутный фикс. Дальше Шаман подцепляет свежий образ и по кнопке раскатывает его на стейдж. Ну не красота, а?

И так как этот процесс находится в ведении разработчиков чуть более чем полностью, у нас есть возможность его упрощать. Меня, например, все-таки расстраивает необходимость сначала идти в GitHub, чтобы посмотреть статус билда, а потом в Шаман чтобы нажать на заветную зеленую кнопку для выкатки образа. После незначительной встряски коллег из инфраструктуры выяснилось, что последний предоставляет API, ручку которого можно дернуть из Github Actions с адресом для деплоя и идентификатором образа для деплоя. А это значит, что деплоить код можно полностью автоматически!

Когда что то идёт не так

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

Так нужно ли деплоить разработчику?

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

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

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

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

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

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

Как происходит деплой в вашей компании? Считаете ли вы наш подход с одной кнопкой оптимальным или вам нравятся другие варианты выкатки новых сервисов и обновлений? Поделитесь мнением в комментариях.

Подробнее..

Delivery Club x GIST

10.11.2020 12:07:03 | Автор: admin


Привет! Меня зовут Илья Воробьёв, в Delivery Club я отвечаю за направление клиентских продуктов. Вместе с Андреем Евсюковым я расскажу о том, как в растущей команде мы пересобирали процессы планирования и к чему это привело.

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

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

С чего всё началось


К лету 2019 года переход к кросс-функциональным продуктовым командам дошёл до финальных стадий во всех продуктовых направлениях Delivery Club. В итоге мы получили понятный и достаточно предсказуемый темп движения на уровне менеджера продукта и разработки (кстати, про это мы уже рассказывали тут), но на контрасте стали более заметны трудности уровнем выше взаимодействие продуктовых команд и менеджеров продукта со стейкхолдерами.
Мария:
Год назад с каждой командой нужно было общаться по-разному. Например, у логистического продукта были планирования раз в две недели. С R&D не было планирования. Мы сидели за соседними столами и нормально всё решали. У остальных команд были разные процессы в зависимости от количества заказчиков, которых нужно подружить между собой и поделить ресурсы, и от количества исполнителей у каждой из команд.


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


Стас:
До внедрения GIST у нас применялся классический подход, когда компания находится в стадии переходного периода, внутри продуктов часто творился хаос. У менеджеров продукта был свой roadmap, но у разработчиков не было к нему доступа. Product-менеджеры где-то что-то фиксировали и с этим работали. Выдержки в виде продуктового описания приносили командам разработки, которые формировали технические требования. Появилась потребность весь этот хаос упорядочить, потому что работать становилось очень сложно.

Проблемы быстро обострялись, и этому способствовали:

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

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

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

  • Не очень понятно, кому нести задачу. Вроде бы, надо менеджеру продукта, но какому? А в каком виде?
  • Неясно, что дальше произойдет с задачей. Кто и как её будет делать? Когда будет готова?
  • Нет прозрачного способа ускорить выполнение задачи (а ведь она, конечно же, самая важная).

Первую проблему было не так сложно решить: определили ответственных менеджеров, и поток задач потёк в нужную сторону. Но тут-то выстрелили две другие проблемы: не имея прозрачного процесса приоритизации, стейкхолдеры ринулись ускорять свои инициативы очень простым и широкодоступным способом давлением. Вспоминают Антон Сокольников и Мария Чебакова:

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

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

Мария:
За 1,5 года количество команд разработки выросло в два раза, а количество людей примерно в три. У них уже тогда было какое-то количество заказчиков. Проблема в том, что заказчиков было больше, чем ресурсов. В такой ситуации всегда возникает делёжка. В нашем случае она была не слишком структурирована: всё зависело от силы заинтересованности конкретного человека в решении конкретной задачи.

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

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

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

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


Иногда сессии по разбору задач растягивались на долгие часы и выглядели как-то так.

Поиск пути


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

Запросы удалось уложить в четыре лаконичных пункта:

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

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

Для заполнения пробелов в коммуникации и планировании стоит ввести новую роль в команде?


Часть задач по коммуникации и сбору требований можно возложить на определённого человека. Зачастую для этих задач в компаниях создаётся институт PMO, и в командах появляются менеджеры, сосредоточенные на выстраивании коммуникации и сведении множества интересов. И хотя этот подход позволяет закрыть пробелы и облегчить жизнь команде и стейкхолдерам, у него есть недостатки:

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

Мы решили обратиться к этому средству, если не сможем найти другого решения.

Существующего процесса будет достаточно, если внедрить систему скоринга?


Баталий на встречах можно избежать (ну, или хотя бы снизить накал страстей), если внедрить общую и понятную для всех систему оценки идей и гипотез. В голову сразу приходят подходы RICE (Reach, Impact, Confidence, Effort) или ICE (Impact, Confidence, Ease), которые позволяют при заполнении показателей получить почти автоматическую приоритизацию.

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

В итоговой реализации GIST мы действительно оцениваем Impact и Effort, но не пытаемся свести оценку задач к какой-то единообразной шкале. Но ICE мы тоже не без успехов используем в некоторых командах как вспомогательный инструмент.

Может выделить в команде слоты под задачи каждого из стейкхолдеров (или группы стейкхолдеров)?


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

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

Подойдём системно и перестроим процесс!


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

Изучая практики с рынка, нас заинтересовали подходы Итамара Гилада (Itamar Gilad, кстати, очень крутой дядя с большим количеством интересных трудов). Работая в Google, он собрал и внедрил этапную систему работы над задачами, которую назвал по первым буквам этапов жизненного цикла работы GIST: Goals, Ideas, Step-Projects, Tasks.

Базовые принципы подхода:

  • Goals цели, которые обозначаются командой на достаточно продолжительный промежуток времени. Они должны быть измеримы и понятны. При генерировании идей команда, менеджеры и стейкхолдеры сосредоточиваются на достижении общих целей.
  • Ideas любой член команды может закинуть идею. Команда регулярно приоритизирует и разбирает идеи, выделяет минимум, который позволит проверить ценность предложения минимальной ценой.
  • Step-Projects большие комплексные идеи разбиваются на этапы, которые можно сделать относительно быстро и проверить жизнеспособность и ценность на реальных данных. Чем быстрее такой проект можно завершить, тем лучше.
  • Tasks декомпозиция проекта на конкретные задачи, которые команда будет брать в разработку.
  • Каждый из этапов команда разбирает на регулярных сессиях и сосредоточивает ресурсы на идеях, которые приносят наибольший результат.



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


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

Have Space Suit Will Travel


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

При этом какие-то части процесса не были описаны Итамаром совсем, а некоторые вполне конкретно обозначены, и более того, многие компоненты уже были у нас внедрены:

  • Этапы Step-Projects и Tasks перенести на наши реалии было нетрудно: команды уже работали в рамках двухнедельных итераций, умели декомпозировать и запускать задачи в хорошем темпе (напоминаю, что детали можно посмотреть в этой статье).
  • C Goals тоже не было проблем. На уровне всего Delivery Club есть понятная стратегия развития, которая довольно просто трансформируется в цели и задачи на уровне команд и направлений. Например, у логистики, с которой мы и хотели начать пересобирать процессы, есть хорошо измеримые цели по загруженности курьеров, среднему времени и стоимости доставки заказа.
  • Самая мякотка для нас заключалась в этапе Ideas: как правильно научиться собирать идеи и выстроить работу по их приоритизации.

Чтобы разобраться с идеями, мы провели мысленный эксперимент в поисках ответа на вопрос: А как должна выглядеть каждая идея, чтобы в момент приоритизации мы могли без проблем понять, что важнее?.

Идея и как её создать


Рассмотрев успешные кейсы в Delivery Club, мы выделили несколько общих факторов:

  • Почти у каждой выстрелившей идеи или гипотезы было проработанное бизнес-обоснование. Например, в начале 2019 года часть команд клиентского направления приступила к проработке решения по запуску доставки продуктов из магазинов. Но до перехода к проектированию мы очень подробно изучили динамику изменения рынка онлайн-ритейла за последние годы и перспективы роста на будущее. Это позволило сразу сфокусироваться на модели маркетплейса для магазинов решения, которое в полной мере расцвело в безумный 2020 год.
  • Время на проектирование и реализацию в продукте всегда было ограничено либо внешними факторами, либо самой командой. Стараясь уложиться в срок, ребята находили оригинальные решения и отрезали всё, что не было важно для проверки гипотезы на запуске. Подчеркнём, что короткие итерации в разработке это не что-то новое или революционное. Хитрость в том, чтобы у команд было изначальное ограничение на количество итераций для финального решения. Кстати, в книге Shape Up Райана Сингера есть подробный разбор этой механики и её использования для развития продукта в Basecamp.
  • Инициатор гипотезы работал в тесной связке с менеджером продукта и командой на протяжении всего процесса: от проектирования и разработки до запуска и оценки результатов. В ряде случаев такое вовлечение позволяло отказываться от реализации на ранних этапах. А где-то раскопать несколько новых идей и гипотез на следующие этапы.

В этот момент проявились контуры того, как мы хотели построить работу:

  • Любой член команды может завести идею и положить её в общее пространство.
  • У идеи должен быть набор обязательных параметров к заполнению:
    • Суть.
    • Почему возникла идея и какую ценность она несёт. Чем больше здесь доказательств, тем лучше. Именно из этого и складывается Impact, который кратко описывается.
    • Как выглядит верхнеуровневая реализация по мнению инициатора.
    • Какой результат ожидаем и почему.
  • Менеджер продукта будет периодически просматривать новые идеи с командой и давать комментарии по описанию, а также дополнять идею данными со своей стороны и фиксировать ограничение по времени на поиск и реализацию решения (это отражает для нас Effort).
  • При первичном разборе часть идей будет склеиваться с уже существующими, часть будет отсеиваться, а часть наполняться деталями. На обсуждение выносим те идеи, которые инициатор готов защищать не только силой своей харизмы, но и набором фактов с пониманием ограничений на реализацию.
  • Раз в две недели проводим общую встречу по приоритизации, на которой происходит три важных события:
    • инициаторы публично защищают свои идеи;
    • команда разбирает результаты завершенных проектов;
    • пересматриваем приоритеты по задачам, которые находятся в бэклоге, и команда сообщает, что уйдёт в разработку далее.


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

  • Настроить инструмент для сбора идей. В нашем случае это задача в Jira в определённый проект.
  • Упростить человеку, который добрался до заведения идеи, её правильное заполнение. Для этого настроили необходимые поля и добавили предзаполненные подсказки в описании.
  • На заведённую идею нужно получить обратную связь. Назначили менеджерам продукта время для разбора новых идей. Чтобы ничего не терять, установили правило вести переписку только в комментариях в Jira-задаче.
  • Подготовить идею к защите помогает менеджер продукта: рассказывает, как дособрать часть данных, и совместно с командой закладывает предварительный слот на проектирование и реализацию решения.
  • Защитить идею на одной из приоритизаций предстоит самому инициатору. Менеджер продукта с командой фокусируются на защите предварительных деталей реализации и отстаивают слот на реализацию.
  • И самое важное: о новом подходе нужно рассказывать. Поэтому после первых пробных шагов мы стали рассказывать о подходе внутри компании. Теперь и вы об этом читаете.

Как проходит защита


Стало понятнее, но последним пробелом остаётся сама защита. Да и как проходит встреча по приоритизации, тоже неясно. А устроено это так:

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



    • Inbox список новых идей. Задачи из этого статуса регулярно просматривают менеджеры продукта, помогая сформировать правильное описание и дойти до защиты.
    • Pitch идеи на защиту, которые будут обсуждаться на ближайшей приоритизации. Успешная защита означает перемещение в бэклог.
    • Backlog, Next, Now отражают состояние защищённой идеи в бэклоге. Соответственно, ожидаем реализации в рамках квартала, следующего спринта, или уже следим за реализацией.
    • Analysis запущенные проекты, по которым команда и стейкхолдеры должны собрать результаты и оценить, насколько идея была успешна (или неуспешна) и почему.

  • У самих задач на доске для наглядности вывели поля Impact (влияние идеи на бизнес и продукт) и Effort (какое время команда берёт на проектирование и реализацию решения). Оба значения заполняются в свободной форме. Обычно в Impact попадает несколько ключевых метрик и прогнозируемые изменения, а в Effort количество спринтов на реализацию.
  • Итогом каждой встречи должно стать следующее: колонка Pitch пуста, BacklogNextNow отражает актуальное положение дел, а в Analysis остаются только те задачи, по которым ещё не набралось достаточно данных.
  • Пара слов про защиту. Инициатор должен отстоять идею, команда и менеджер будут бороться за слот на реализацию. Ограничений по формату нет, но на каждую защиту выделяется 5-7 минут, за которые нужно успеть доказать ценность идеи, согласовать ограничения на реализацию и перенести в бэклог. Изначально мы предполагали собирать на защиту комитет из людей с независимой позицией, но решили отложить эту схему на случай крайней необходимости.

Внедрение


Всё вышеописанное, начиная от формата задач до повестки встреч, зафиксировали в Confluence. Потом завели проект в Jira и настроили Kanban-доску. На этом простая часть закончилась и началась сложная внедрение.

Справедливости ради, не во всех направлениях проблема стояла одинаково остро, поэтому пилотировать мы начали там, где болело больше всего. А больше всего болело в направлении логистики.



Какие шаги предприняли:

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

В первые пару месяцев получалось довольно тяжко. Вот как вспоминают и оценивают тот период Мария, Антон и Стас:
Мария:
Хорошо помню переход на GIST. Сначала было больно, потому что новый процесс ставил людей в новые рамки. Каким бы они ни были благом для конкретного человека, воспринимались в штыки. Выгоды были понятны, но когда ты их ещё не получил, а ограничения уже есть, это вызывает протест. Когда внедряли GIST в первой команде, люди сопротивлялись. А когда дошли до третьей команды, люди уже сами просили внедрить GIST.

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

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

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

В тот момент как раз поступила крупная задача на 2,5-3 месяца разработки. Мы её оформили в Идею, выделили MVP это и был наш Step-Project. Дальше его поделили на таски и попытались поставить их на продакшен за два спринта в составе Step-Projectа. Поняли, что идея нам подходит, есть прогресс со стороны бизнеса. Дальше сформулировали следующий этап итерации.

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

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

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

Эти встречи позволили:

  • Объяснить правильную структуру и принципы описания идеи.
  • Выстроить и зафиксировать прозрачные для стейкхолдеров цели.
  • Научиться получать верхнеуровневые оценки по разработке на ранних этапах.
  • Мыслить в формате влияния на бизнес и метрики.
  • Технической команде приносить и высказывать продуктовые идеи.

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

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

И жили они долго и счастливо?


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

Второе это про другой аспект прозрачности: понятно, когда будет сделана задача, которую ты ждёшь. Либо она взята в работу, либо нет. Не нужно звонить менеджеру раз в неделю и спрашивать, когда 1 из 20 задач будет сделана. Это новый и более формализованный способ коммуникации, у которого есть простые и понятные правила. Людям становится намного легче общаться, причём не разговаривая. Всё собрано на одной доске. Экономится куча времени. Важно любить время других людей и уважать его. Не только своё.

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

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

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

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

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

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

  • У команд и стейкхолдеров вырабатывается привычка подробно оценивать идеи с точки зрения влияния на бизнес и продукт. А это, в свою очередь, отличная предпосылка к поддержанию и развитию целеполагания по OKR.
  • Ориентация на единый инструмент (Jira) и возможность отследить движение идеи добавляет прозрачности и снижает использование сторонних решений (меньше Google-таблиц и их аналогов, да).
  • Понятные шаги по созданию и продвижению идей постепенно вовлекают в работу с продуктовыми командами людей из бизнеса, обычно далёких от разработки.

Результаты в направлении логистики нас порадовали, и началось постепенное внедрение в других командах. К осени 2020 года GIST проник во все продуктовые направления Delivery Club, но не везде прижился как основной процесс.

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

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

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

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

Как оценить процессы в компании комментарии разработчика

02.05.2021 14:07:38 | Автор: admin

Собеседование только полдела. Наинтервью невсегда очевидно, как насамом деле будут устроены рабочие процессы, иреальность может оказаться нетакой радужной. Как выбрать тот проект, где будешь по-настоящему счастлив? НаStack Overflow пользуются тестом Джоела это 12вопросов, которые должны помочь оценить качество работы команды.12простых вопросов, да/нет ответы. Ноэтому списку уже 20лет, иGergely Orosz пообщался сомножеством разработчиков иадаптировал тест ксовременным реалиям. Приводим перевод нескольким блоков икомментарии разработчика: онкак раз недавно вышел работать вновую компанию.






Необходимо, нонедостаточно: 3требования кновой компании


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


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


достойная вашего труда компенсация: получаютли зарплату, которая соответствует рынку?
гибкие рабочие часы: могутли гибко организовывать своё рабочее время?


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


Начиналось всё неплохо: позвали внебольшой проект. Развивается стремительно, укоманды хороший технический уровень это очень воодушевляет. Апотом всё куда-то скатилось.

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

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

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

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

Аещё мне нравится работать удалённо. Возможность выбирать свой ритм жизни хотелось сохранить.

Может, работникиIT посравнению сдругими специальностями иизбалованы: новедь сдругой стороны, если все компании примерно выровнялись поуровню компенсации, кофе иплюшкам накухне IT-специалисты реально могут себе позволить выбирать тот проект, который по-настоящему откликается, чьи ценности тыразделяешь. Зачем терпеть скучный проект инеприятную команду? Артём С.


5вопросов про взаимодействие скомандой


Самостоятельные икреативные люди процветают вкомпаниях, где есть ясность процессов, возможность автономности содной стороны исотрудничества сдругой. Накакие стороны работы команды Джерджели предлагает обратить внимание? Могут выполняться 4пункта из5.


  • Обусловленность действий. Естьли процесс, который позволяет делиться бизнес-запросами, почему нужно выполнить туили иную задачу? Дорожная карта продукта, OKR, цели компании.
  • Бэклог/дорожная карта продукта иинженеры, которые вносят вклад вэти процессы. Естьли укоманды чёткий бэклог, который позволяет ответить навопрос над чем будет работать дальше ипочему? Могутли инженеры вносить предложения вдорожную карту? Приоритизируютсяли благодаря этому предложения попогашению технического долга?
  • Прямая коммуникация при возникновении проблем. Могутли разработчики напрямую общаться сразработчиками других команд? Или они должны пообщаться ссвоим менеджером, который поговорит сдругим менеджером, который поговорит сещё одним менеджером, который поговоритс
  • Коллаборация соспециалистами других сфер. Могутли разработчики работать напрямую сдизайнерами, продакт-менеджерами, дата сайентистами идругими стейкхолдерами, неприбегая кпомощи посредников, например, менеджеров?
  • Инициатива поощряется. Вознаграждаютсяли люди сновыми идеями иинициативами, или считаются, что они лишь зря отвлекают внимание?

За12лет вIT яуспел поработать ивкрупных, ивмелких компаниях. Бросил какое-то место, просто потому что понял, что нецепляет. Ипришёл работать встартап почти бесплатно: потому что попал всуперскую идейную команду. Команда горела: вгод чемпионата пофутболу вРоссии мызапартнёрились сFIFA, Apple сделал фичеринг ивсё это без бюджетов, наодном энтузиазме. Найти правильную схему для монетизации несмогли, поэтому решили разбежаться, носама атмосфера это было круто.

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

Ещё ипоидеологическим представлениям совпали: Wheely отказались предоставлять данные опередвижении своих пользователей.

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


5вопросов про инженерную культуру


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


  • Различаютсяли этапы функциональная готовность иготовность кпродакшену. Естьли различия между прототипом, MVP иготовым кпродакшену продукту? Естьли чеклист для оценки качества, что продукт готов квыпуску?
  • Код ревью итестирование являютсяли они частью рутинного процесса разработки, аихотсутствие редким исключением?
  • Налаженли процесс непрерывной интеграции. Естьли увас процесс непрерывного развёртывания, чтобы отправлять код прямо впродакшен, иесли нет, томогутли разработчики отправлять собственный код вэто окружение?
  • Oncall невлияет наздоровье сотрудников. Для проектов, где есть oncall, следятли затем, как онвлияет насостояние людей иработу над продуктом?
  • Доступ кисходному коду. Можетли любой разработчик просматривать ивносить свой вклад висходный код?

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

Аоказывается, можно созваниваниваться только раз вдень по15минут, иэтого достаточно всем. Так вообще работает? Все Agile, Scrum ипрочие методологии неработают при разлаженности команды. Достаточно самого минимального усилия, чтобы запустить процессы икоманде было удобно работать.

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


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


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


Акак вам кажется, это возможно? Ичто важнее всего вкомпании? Напишите, пожалуйста, вкомментариях.



Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru