Всем лучиков добра! Меня зовут Владимир Маркиев, но вы можете звать меня просто Колян.
Я работаю техническим писателем в компании.
Мы разрабатываем систему электронного документооборота, и в этой статье я хочу рассказать, как мы разделили один большой отдел на несколько команд. Не буду пересказывать очередную историю успеха, а обрисую процесс со своей субъективной точки зрения.
Всё переверну, приперчу глупыми шутками и всё в таком духе.
Как и у любой другой компании, у нас была своя команда разработчиков, а точнее две большие команды.
Одна команда разработала один продукт, другая — второй.
Все шло хорошо, приходили новые разработчики, команды постепенно росли, и в какой-то момент стало понятно, что большие команды только усложняют процесс разработки и делают взаимодействие неудобным.
Когда одни и те же ошибки исправляются несколько раз разными людьми, это неоптимально.
Неоптимально также, когда на утреннем стендапе присутствуют 22 человека и пятиминутный разговор о проблемах приводит к получасовому сеансу психотерапии для одного-двух разработчиков.
Поэтому мы решили перейти от проектных команд к кросс-функциональным командам.
Сейчас я все объясню.
ВНИМАНИЕ: прежде чем я начну, будьте готовы к неожиданностям при чтении этой статьи.
Если текст кажется вам полным сарказма, не воспринимайте его слишком серьезно.
Если текст вас оскорбляет, не читайте его.
Спасибо!
Вы поняли, что сказали?
Сложное слово «кросс-функциональный» просто означает, что все команды делают всего понемногу.Таким образом, каждая команда выполняет задачи из разных проектов и знает весь продукт, а не только его часть.
Думаю, понятно, почему каждому так важно знать обо всем понемногу, но на всякий случай поясню:
- Каждый разработчик видит код разных проектов и немного понимает, «как это работает».
- Если кто-то заболеет, уйдет в отпуск или уволится (а такое случается), его работу возьмет на себя кто-то другой.
- Каждый вместе делает продукт, а не отдельную его часть.
Встреча прошла, естественно, онлайн.
Не все сейчас ходят в офис, а офисы у нас есть в двух разных городах.
Некоторые даже впервые показали свое истинное лицо.
Я имею в виду не только аватарку.
Все единогласно перешли по ссылке на Миро, где наш заботливый руководитель Денис заранее подготовил стикеры, на которых каждый записывал то, что хочет сделать.
Затем всех попросили занять места за четырьмя столами.
Столы были виртуальными, поэтому перекусов не было, но на каждом месте были надписи «фронтенд-разработчик», «бэкенд-разработчик», «бизнес-аналитик», « тестер ", ой, извините, "QA-инженер", "технический писатель".
Три постоянных команды и один сервисный тип - помогает другим и координирует работу.
Это потому, что у нас пока не так много бизнес-аналитиков и есть только один технический писатель( это я.
Привет, мама!).
Где-то после этого была еще одна встреча каждой команды, где долго и в лучших традициях древнегреческих мудрецов говорили о том, кто должен быть «лидером команды», а кто должен ходить на собрания команды и почему они могут быть разными.
люди.
После разделения каждая команда обладает всеми необходимыми атрибутами успешной команды:
- Глупые имена: Вжик, Горыныч, БЭМС (Боевой, энергичный, Молодой, Милый), Звездочка.
- Логотипы с картинок, найденных в Интернете.
- Командный дух, компетентность и опыт
Распространение YouTrack
Команды есть, теперь надо как-то работать.Мы работаем в YouTrack, а точнее с его помощью.
Да-да, я знаю, что Agile, спринты, ежедневные стендапы и все это от зарубежного дьявола и никому не нужно.
Если вы согласны, то пропускайте этот раздел и идите лес далее в статье.
Я постараюсь изложить это кратко и по существу.
Раньше у нас был один общий ютрек: все задачи в одной куче, которую распределял наш многозадачный лидер Денис.
Сейчас у нас остался один общий ютрек, но задачи распределяет небольшой бригадир, избранный народом.
Раньше каждые две недели мы планировали один общий спринт, на который можно было потратить полтора часа времени, а теперь команды планируют спринты сами.
Или они могут полностью отказаться от всех хитростей и планирования, если проголосуют таким образом.
Выгода в том, что теперь на планирование тратится значительно меньше времени и нервов.
Мне вообще не нужно участвовать в планировании.
В чем смысл? В любом случае, мне придется документировать каждое требование позже, поэтому я документирую, а не планирую.
Раньше у Ютрека было два проекта: платформа и веб-клиент. У нас теперь есть общепроизводственные задачи, которые могут включать в себя любой проект. Были задачи типа задач WebC и DV5, но они стали просто TSK (может быть и WebC, и DV5, или вообще что угодно).
Раньше ошибки записывались как обычная задача, а теперь они записываются в специальную задачу типа ERR. Вы видите заголовок и сразу понимаете, где зарыта собака.
У каждой такой задачи есть поле «команда», в котором указаны ответственные.
Вы приходите на такой запрос, видите, кто несет ответственность, и сразу знаете, к кому обратиться, чтобы узнать информацию.
Ещё у меня появился свой тип задачи ТСК — задача по документированию.
Мои спецзадания не имеют проверки и тестирования, они сначала открыты, потом в работе, потом закрыты.
Все.
Расскажи, как круто у тебя получилось
Работать действительно стало намного веселее.Появился четкий ритм.
Утром проводится стендап (5-15 минут) и обсуждение проблем команды, затем избранные приходят синхронизироваться и поделиться проблемами на собрании команды (обычно 5-7 минут).
Каждые две недели проводится ретроспектива (как мы работали) и планирование (что будем делать дальше), а также общекомандная демо-версия (показать всем, как работает то, что мы сделали за 2 недели).
И это не полуторачасовые встречи, как раньше, а действительно динамичные и полезные мероприятия.
Демо мне особенно нравится, потому что теперь мне не придется часами сидеть и корпеть над требованиями, в том числе и фантазировать «что здесь имелось в видуЭ» Как я могу это задокументироватьЭ» Команды сами все покажут и объяснят! Ладно, кого я шучу, мне всё равно приходится часами ковыряться в требованиях, потому что я тупой.
Команды стали максимально автономными и независимыми.
Они не ограничены ничем, кроме достижения поставленной цели – выпуска продукта.
В своих небольших командах коллеги разрабатывали собственные приемы автоматизации, специальные алгоритмы взаимодействия и т. д. Например, в «Звездочке» была разработана система достижений за количество закрытых требований в спринте.
Если они выполнят требования XX, YY, NN, они получат одну, вторую и третью звезду соответственно.
Более того, они его полностью закроют, включая документацию.
На мой вопрос «а что, если я не успею документировать их запрос и его не закроют», мне ответили, что могут вежливо попросить меня поторопиться.
Это дает мне некоторую власть над всей командой.
Власть опьяняет. В любом случае получилось здорово! Демократия, открытость и независимость – именно так я бы охарактеризовал нынешний процесс.
Ты за рулём, не может всё быть так гладко
Может быть, я за рулем, но совсем немного.
Так: 
Дело в том, что в нашей компании налажена система code review. Это когда один разработчик приходит к другому и говорит: «посмотри, какой классный код я сделал!», а второй ему отвечает: «почитай чистую архитектуру Мартина, тогда и поговорим».
Короче говоря, у нас было несколько вариантов организации обзоров, и мы не знали, какой из них выбрать:
- Итеративный обзор.
- Мы взялись за задачу.
Мы расширились и внесли улучшения спереди и сзади.
- Прежде чем передать его на утверждение бизнес-аналитику, мы проверяем всю функцию.
В то же время мы модифицировали development. (Существует мнение, что развитие в отдельных ветках осталось в прошлом.
Так что пусть будет так.
)
- Они хорошо поработали, довели отзыв до согласования и передали на приемку.
- Если необходимы изменения, повторите предыдущие пункты.
- Если никаких доработок не требуется, отправляем на тестирование.
- Мы занимаемся исправлением ошибок.
- Когда все будет готово, мы рассмотрим изменения исправления в целом, сделаем обратное слияние и объединим его в разработку.
В этом случае обзор будет немного объемнее и сложнее, но делать его нужно будет реже.Одна команда сможет проверять другую, код будет коллективной собственностью, дети в Африке не будут голодать, и на Земле будет рай.
Только не спрашивайте, как это работает, моя работа — рассказать вам.
- Мы взялись за задачу.
- Проверка через мерж-реквесты.
Это работает следующим образом:
- Один разработчик написал код и перевел его на проверку.
- Автоматически создается отдельная ветка и назначается рецензент. Рецензент должен обладать теми же знаниями, что и автор кода.
Ну, подобно тому, как разработчик клиента не может проверять разработчика сервера, сишарпер не может проверять Javascripter и т. д.
- В этой ветке коллеги обсуждают чистоту архитектуры, а потом ветку сливают в разработку, и все довольны.
- Организовать его можно напрямую через GitLab, минуя апсорс, в котором все было сделано до разделения.
- Один разработчик написал код и перевел его на проверку.
Знаете, какой вариант мы выбрали? Нет! Обзоры кода проводятся для каждой задачи или ошибки, если это возможно, внутри команды.
Если это невозможно, то перекрестная команда.
Обзор создается на основе коммитов по задаче или ошибке в какой-либо ветке.
Неудобные вопросы после разделения на команды
- Как будет происходить регресс?
- Ожидание: Все задачи регрессии будут равномерно распределены по командам.
Или одна команда выполняет большую часть работы, а другие помогают.
- Реальность: После разделения мы еще не достигли точки регресса, поэтому практического подтверждения нет.
- Ожидание: Все задачи регрессии будут равномерно распределены по командам.
- Кто будет забирать случайно найденные ошибки из общего чата?
- Ожидание: Под индивидуальную ответственность.
Нашли, записали, а дальше за задачу берется та команда, которой задача больше всего нравится.
Или в зависимости от загруженности.
- Реальность: Вот как это работает. До сих пор проблем не было.
- Ожидание: Под индивидуальную ответственность.
- Как будут распределяться пошлины по ТП?
- Ожидание: Очень просто.
Не команды дежурят, а люди дежурят. Если загруженность ТП высокая, можно подключить людей из других команд. Если нагрузка небольшая, то дежурные могут совмещать дежурство с повседневными делами.
- Реальность: В общем, все так.
В крайних случаях особо большой загруженности можно забыть об SLA и решать проблемы в комфортном темпе.
Но это неправильно и мы этого не делаем, конечно.
Честно.
- Ожидание: Очень просто.
- И как полет сейчас, спустя месяцы?
- Ожидание: Никто не ожидал, что команды будут статичными.
- Реальность: Кто-то ушёл, кто-то пришёл, кто-то перешёл из соседнего отдела.
Как и планировалось, в каждой команде был по одному бизнес-аналитику.
Но разработчиков не хватает.
- Ожидание: Никто не ожидал, что команды будут статичными.
выводы
Короче говоря, разделение на команды — это весело и совершенно безболезненно.Как ни странно, после расставания мы узнали друг о друге больше, чем раньше.
У каждого даже появилась своя карточка с основной информацией о человеке.
Как и его любимые занятия, почему он здесь и к чему стремится.
Очень интересно, мне это нравится.
Новичкам теперь легче присоединиться к небольшой команде, разобраться в процессах и начать работать.
Короче говоря, недостаток людей – это плохо, избыток – тоже плохо.
Если у вас огромная команда и управлять процессами становится сложно, подумайте о ее разделении, это действительно работает. А если вам нравится стиль статьи, подписывайтесь на моя телеграмма .
Если вам не понравился стиль, все равно подпишитесь, возможно Telegram понравится.
Теги: #Карьера в IT-индустрии #Управление разработкой #Управление проектами #развитие #Управление персоналом #Управление продуктом #работа в команде #команда разработчиков #команда мечты #командный дух #команда #реструктуризация #реструктуризация бизнеса
-
Газохимия
19 Oct, 24 -
Платина
19 Oct, 24 -
Почему Мозговой Штурм — Пустая Трата Времени
19 Oct, 24
