Почти любая современная компания полностью зависит от своего ИТ, скорости и качества его работы. Чтобы быть лидером, сейчас нужно очень активно оптимизировать процессы производства, сокращать релизные циклы до 1-3 месяцев и вовлекать каждого отдельного сотрудника в проектирование продуктов и услуг, которые будут максимально отвечать потребностям рынка.
Корень проблемы заключается в том, что предыдущие годы мы были сфокусированы на улучшениях процесса разработки через формализацию ролей, разделение ответственности, создание шаблонов документов, правил приоритезации бизнес-задач, формирование различных комитетов и тп. Это все помогает, но очень немного.
Чтобы оставаться конкурентноспособными, мы должны заглянуть глубже – в корпоративную культуру. Которая определяет ценности, привычки и поведение людей, в том числе внутреннюю мотивацию и ответственность за результат.
Именно через постепенное, целенаправленное изменение внутренней культуры можно достичь на порядок более высокой скорости поставки.
В конце доклада рассмотрим пример конкретных действий, которые вы сможете сделать, вернувшись в понедельник в офис.
-
Log in
-
Join
Watch in our app
Open in app
Единственное что могу заметить… Что часто когда пытаются внедрить Agile / scrum пытаются сопоставить роли PM, тимлида и т.п. Так вот тимлидов и PM в Scrum НЕТ!!!
+2
Да, очень часто сталкиваюсь с таким миксом из должностей и ролей. Отсюда же рождение должностей Scrum Master, Product Owner. Причем под Product Owner кого только не поразумевают от системного аналитика до менеджера продукта.
0
0
+1
0
Не скрамом единым. К тому же он не запрещает назначать другие роли вне каркаса скрама.
Чем больше ролей — тем больше можно раздать медалек и выделить кого нибудь, чтобы не сбежал. Хехе.
0
Может дешевле доску почета передовиков производства завести!?)
0
Бывает даже, что дешевле поднять зарплату. Разные бывают механизмы мотивации. Я их не предлагаю, всего лишь говорю о том, что имеет место быть в реальности.
Перепутать тимлида и пипл менеджера, как сделал автор, это не самое худшее. Нередко позиция тимлида — просто механизм задержать крутого спеца подольше в команде.
0
В общем, получается, что тимлид это гораздо больше менеджер, чем программист.
0
Зависит от команды, если команда я, да Вася, то на управление времени не уйдет почти нисколько, но когда команда переваливает за 5 человек на управление уже уходит большая часть времени. А в команды более 10 человек я вообще не верю, они неуправляемы.
+2
По мне Ваше утверждение так же справедливо как, например, «Программист, получается, больше наборщик текстов». В статье
очень
хорошо обозначены обязанности тимлида, и объем управленческих работ предлагается
приемлемый
.
0
Ну и странный же вывод. Если бы вы внимательно прочитали статью, то увидели бы — там описано, что основная обязанность тимлида именно управлять командой. А непосредственно программирование — это второстепенно. А управление — это менеджмент. Не знаю, что тут может быть непонятно.
Дело в том, что из-за отсутствия четкого понятия, что же такое тимлид, куча народу считает, что это высшая форма программиста. На самом деле, в команде могут быть программисты, которые сильнее тимлида, но все эти управленческие заботы им даром не нужны.
И самые важные качества тимлида (судя по статье) — организаторские способности, умение завоевать авторитет, способность брать ответственность на себя, умение выстроить отношения с командой, коммуникабельность — не связаны непосредственно с программированием — это менеджерские качества.
0
И самые важные качества тимлида (судя по статье) — организаторские способности, умение завоевать авторитет, способность брать ответственность на себя, умение выстроить отношения с командой, коммуникабельность — не связаны непосредственно с программированием — это менеджерские качества.
Вот тут как раз субъективизм — Вам из статьи это показалось наиболее значимым, а мне
Например для себя я определил правило, что тимлид, в командах разработки, обязательно должен принимать непосредственное участие в разработке, то есть писать код, разрабатывать архитектуру и т.п. Это нужно для того, чтобы понимать как устроена система изнутри, без непосредственного участия в разработке такое понимание постепенно сходит на нет.
И если менеджменту уделить процентов 15-20, то это приемлемо. Тимлид все же программист (у команды разработчиков, конечно), и это совсем не ПМ. Не знаю, интересно ли Вам мое собственное мнение, если да, то оно за
спойлом
(далее личный опыт исключительно) Все эти управленческие дела при правильном подходе не напрягают… Я и раньше, например, помогал более слабым членам команд в решении проблем, если они в этом нуждались (еще не будучи на позиции тимлида). Добавить к этому распределение задач? Легко, мы используем довольно эффективный метод оценки временных затрат, которому обучены так же и члены команды. Остаются только коммуникации, но с этим вообще проблем не было никогда. Остается только «умение завоевать авторитет» — но это вышло естественным путем, когда не «выпрыгиваешь из штанов» тебя лишняя порция ответственности не напрягает.
0
Вот тут как раз субъективизм — Вам из статьи это показалось наиболее значимым, а мне
Например для себя я определил правило, что тимлид, в командах разработки, обязательно должен принимать непосредственное участие в разработке, то есть писать код, разрабатывать архитектуру и т.п. Это нужно для того, чтобы понимать как устроена система изнутри, без непосредственного участия в разработке такое понимание постепенно сходит на нет.
То что вам показалось значимым — это как раз пример дополнительных обязанностей, который привел автор статьи. Из того же абзаца (никакого субъективизма, все из статьи):
… это то, что тимлид взваливает на себя добровольно (или принудительно) дополнительно…
… согласно рассуждениям выше, непосредственная разработка не входит в число родных обязанностей тимлида, в некоторых проектах она может быть необоснованна.
То что вам удается обходиться 15% времени на менеджмент — это замечательно. Но, если команда состоит из средненьких программистов, среди которых есть люди с проблемным характером, да еще и руководство компании непростое и любит долгие совещания (и на каждое дергает тимлида), плюс добавим кучу мелких администратвных дел, которые могут быть повешены на тимлида, то тут хорошо, если хотя бы 40% времени останется на непосредственно программирование.
Не даром же на западе в некоторых командах есть отдельно технический лидер (который полностью отвечает за техническую сторону, архитектуру) и тимлид (который больше менеджер).
Ваш личный опыт прочесть было интересно, но я думаю, сколько людей, столько и мнений.
0
40% времени останется на непосредственно программирование.
У меня был опыт работы на проектах и в условиях, где и простому разработчику приходилось тратить по 2-3 часа в день на митинги. Это проблема процессов внутри компании а не конкретных должностей. Вы собственно сами об этом указали. Но если в этих митингах не видно ценности, то может быть имеет смысл поговорить с руководством и как-то оптимизировать процесс? Есть правда еще бюрократия но…
0
К счастью, я еще не встречал команд, где обычных разработчиков выдергивают каждый день на 3 часа на митинги) Это, должно быть, очень богатые компании, если могут себе такое позволить =)
По поводу тимлида, штука вот в чем (из статьи):
тимлид — интерфейс команды разработки
То есть, главное — это донести до команды задачу, правильно распределить ее между программистами и обеспечить выполнение, а не стараться отгородиться от всего, лишь бы сидеть и самому заниматься имплементацией.
Хорошо, сегодня тимлиду удалось оптимизировать митинги внутри компании, сократив их время на 50%, а завтра появятся подрядчики, с которыми тоже нужно проводить митинги. И тимлид закроет свою IDE и пойдет это делать. Потому что управление для него приоритетней, чем непосредственно программинг.
0
Потому что управление для него приоритетней, чем непосредственно программинг.
И это правильно, иначе он был бы просто программистом а не руководителем отдела разработки. Есть еще такие персонажи как техлиды, и они обычно кодят больше.
0
Ну вот. Из этого вывод, что если у тимлида на кодинг остается всего 30% (к примеру) от всего рабочего времени, это никакая не проблема, а просто особенность должности. И к этому надо быть готовым — не каждый программист хочет расти в таком направлении.
0
Я знаю один интересный прецедент, когда командой python-разработчиков (в рамках весьма крупной компании) руководил PHP разработчик. И там процент времени занятый кодом — 0%. Чисто управление командой, улучшение процесса разработки, собеседования и т.д. И ничего, все хорошо работали, процессы развивались и все такое. По хорошему тимлид вообще кодить не должен, но может. Но по итогу спустя два года (если память не изменяет) ему стало грустно от того что он не кодит.
0
Было бы очень интересно услышать мнения непосредственных участников. Возможно это случай удачного разделения обязанностей тимлида между несколькими членами команды.
0
> Вообще хотел обойтись без этого пункта, но совсем про него не упомянуть нельзя.
А мне вот наоборот интересно было бы услышать у кого какие способы сплочения коллектива. Может традиции какие-то, пицца по пятницам?.. Рассказывайте, очень интересно услышать! 
По теме:
Сам я тимлид, свою миссию вижу именно как помочь команде комфортно, профессионально и в сроки выполнять задачи. А так же давать PM’y оценку работ и консультировать по всевозможным техническим вопросам. И да, я пишу много кода, рисую интерфейсы, выдумываю архитектуру и много еще всего, хотелось бы делать этого меньше, но пока никак
+3
Про тимбилдинг говорить не хотел, так как сам не специалист и не верю в него.
По крайней мере в тот, который по инициативе администрации организуется.
Тимлид, кстати, тоже как часть администрации воспринимается, и от его лица тимбилдинги проводить тоже плохая идея.
Есть тонкий момент в том, что просьба со стороны уважаемого командой тимлида для многих равносильна указанию.
Но когда речь идет о добровольных мероприятиях тимлиду некоторым отказать сложно, и уже не понять, по доброй ли воле идет сотрудник на мероприятие.
Хорошая идея взять в команду душу компании, который(ая) будет перехватывать инициативу во внерабочее время, это работает.
Мероприятия практикуют самые разные, просто пойти в бар, с гитарой на лужайку, в ЧГК сыграть (https://igry-razuma-intellektual.timepad.ru/events/), играют и в покер и настольные игры, катаются на велосипедах.
Но лично у меня есть сомнения, что переход в отношениях из коллег в друзья-товарищи играет большую роль в «повысить эффективность взаимодействия между членами команды» — потому и написал в кавычках. Считаю, что больший выигрыш в таком переходе у компании, за счет которого она крепче привязывает к себе сотрудников.
По теме, у вас вполне стандартный набор обязанностей, может в вашем случае их передача кому-то и необоснована?
+1
Я тимлид и, в отличие от предыдущего оратора, верю в тимбилдинг. К сожалению, моя компания не оплачивает такие штуки, поэтому приходится изобретать самому. У меня психологическое образование, так что мне, вероятно, немного легче.
Я считаю, что хорошая команда складывается, когда с одной стороны, все разбираются в некой широкой доменной области, а с другой ещё и в какой-то своей узкой. Соответстенно в час нужды все всем могут помочь и все знают к кому можно обратиться за помощью. Я, как тимлид, снимаю компетенции со всех и могу помочь кому угодно — и стараюсь делать это по мере необходимости. Удивительно н алюдей действует ощущение того, что их коллега может помочь решить почти любую проблему. Они становятся открытыми, с радотью изучают новое и помогают друг другу.
Итак, основа крепкой команды, с моей точки зрения — это доверие и взаимопомощь.
Рядом с такими непонятными и неформальными вещами, как ни странно отлично уживаются кодревью, мёрджреквесты (только сейчас к ним пришли, к сожалению, надо было раньше) и другие штуки, которые помогают нам следить за качеством кода друг друга. Надо сказать, что холивары тоже случаются — их помогает решить либо демократия, либо диктатура — к счастью, тимлид может выбирать любую модель в зависимости от ситуации. Диктатура может быть актуальна в том случае, если тимлид больше знает об итоговых целях чем команда — так тоже бывает. Очень часто разработчиков не особенно интересуют глобальные цели, а больше интересуют локальные задачи. Это нормально и к ним надо относиться с пониманием — не все обладают имперскими амбициями.
Да, понимание — это тоже отличная штука, которая помогает создать команду. В атмосфере понимания кодревью проходят гладко, ошибки правятся быстрее и зачастую лучше. Все понимают, что замечание — это не желание придраться, а желание добиться лучшей цели.
Насчёт традиций: очень классно если получается их создать. К сожалению, как-то так получилось, что в моей нынешней команды нет ничего, что объединяло бы всех членов команды (или мне пока не удалось этого нащупать) — пива не пью я, а в настольные игры не играет дизайнер, не всех интересует DevOps, ну и так далее. Завидую тем, кто общую тему таки нашёл
Ещё важная лично для меня вещь — это эмпатия, то есть способность хорошо воспринимать эмоции окружающих. Может кто-то считает это выдумкой, а кто-то считает, что эмоциям на работе не место, но я в эти концепции не верю. Я считаю, что понимание эмоций команды ведёт к тому, что никто никого не доведёт до такой вспышки эмоций, каковая помешает ему работать. С эмоциями надо уметь работать, да.
P.S. Не бейте больно, это просто мой, причём не очень большой, опыт. Ваш может быть частично или совсем другим.
+6
Спасибо за то, что поделились, очень интересны разные точки зрения.
Мое недоверие направлено скорее на то, как тимбилдинг реализуется на практике, похоже на карго-культ, тимбилдинг ради тимбилдинга.
Доверие и взаимопомощь неплохо развиваются и при повседневной работе, если обстановка в коллективе к тому располагают, если же нет — никакие специальные мероприятия этому не помогут.
На практике же часто бывает так, что на работе у нас каждый сам за себя, причем именно руководство создает такую обстановку, а потом, внезапно, на специальном мероприятии, специально обученные люди (внутренние или внешние), за деньги внушают коллективу, что они — команда.
Такой тимбилдинг мне не по душе.
Лучше всего, когда инициатива командообразования рождается и поддерживается внутри команды, причем лучше когда это происходит не по инициативе администрации.
0
В качестве тимлида — главная тема из шуток по сроки «выпустить в продакшен проект самому за две недели, если все пошло в пропасть». А в целом, нужно не знать абсолютно все, а уметь помочь и подсказать в каком направлении «копать» по проекту. Сейчас в планах проводить командные тренинги в неформальной обстановке, когда видишь, что человек не умеет достаточно хорошо пользоваться каким-то инструментом: git, ide, браузерные dev-tools и т.п…
И, кстати, да. У нас укрепилась традиция уже на протяжении трех лет — пицца по четвергам.
0
Пицца по пятницам очень-очень легко вырождается в «Нафиг мы собрались? А, ну да, пиццу поесть и только.»
0
Есть ещё одна сторона медали в работе тимлида — обратная связь команде. Без обратной связи люди не понимают, в том ли направлении они движутся. Это правда важно.
Когда обратная связь положительная (ну или хотя бы нейтральная), то всё ок. Хотя и тут стоит не перестараться (:
А вот когда она отрицательная, это чертовски сложно. Причём в каждой отдельно взятой ситуации сложно по-своему.
С тимбилдингами всё не просто. Особенно когда в команде пара интровертов, что в нашей отрасли встречается чуть чаще среднего, и семейные с детьми.
+1
Обратная связь очень важна в работе тимлида, я отношу ее к инструментам поддержания и развития компетенции, а в некоторых случаях и поддержания настроений в команде.
Давать отрицательную оценку действительно очень сложно, из общих советов: делать это только наедине, кроме случаев когда точно понимаешь, что в данный момент нужно сделать это публично.
0
Очень хорошая статья. Наверное, лучше и не опишешь. К слову про Scrum: возможно кто-то и играет в Scrum без тимлидов, но это создает некоторые проблемы.
+1
Спасибо, всегда можно сделать лучше, было бы время.
Мои изучения Scrum’а и допытывания всяких гуру привели меня к выводу, что для Scrum’а наличие или отсутствие явно обозначенного тимлида — лишь детали реализации, Scrum говорит, что соберите людей вместе, дайте им задачи, не лезьте в их дела, они сами разберутся, а лидер появится сам собой. Но лично я считаю, что подтолкнуть команду к тому, чтобы лидером стал наиболее подходящий для этого кандидат и меньше времени тратилось на борьбу за лидерство (все равно она будет, даже если никто в этом не признается).
0
кто-то играет в скрам без скрам-мастера, в этом проблема, а тимлиды это архаизм, но для небольших проектов годится, немного знает методики управления, немного программирует, способен немного натаскать джунов, но на нормальных проектах, это зло, постоянно тормозящее проект и других разработчиков, просто в силу физической невозможности проффессионально все успевать
0
Фундаментальное различие в том, что в скрам-мастер фокусирует команду на результате (скрам — это жестко прописанные роли, правила и артефакты), тогда как тимлид сам распыляется и не может сфокусировать и четко объяснить свою деятельность, не говоря уже о команде (даже в интернете все пытаются по разному формализавать, и изобретать чем же он занимается).
-1
но на нормальных проектах, это зло, постоянно тормозящее проект и других разработчиков, просто в силу физической невозможности проффессионально все успевать
Расскажите, пожалуйста, что за нормальные проекты такие, чем отличаются от «ненормальных», и почему тимлиды на них еще и тормозить других начинают, а то, признаться, я таких за 10+ лет опыта не видел, что-то новое и неоткрытое!
0
О это обширная тема, я наверно буду на пенсии писать про это мемуары, начиная о том как «тимлиды» предлагали писать в коде сервера компоненты для фронтенда, и заканчивая тезисами о монолитной разработке вместо модульной (loosely coupled), плюс всякие пулл реквесты висящие днями на рассмотрении в то время как дедлайн и проект горит. А также как предлагая лучшие практики, получаешь ответы лида типа «у нас это не принято». Или о приватных звонках «тимлидов», с просьбами срочно прекратить разработку и тестирование продукта, вместо того чтобы обсудить все в общем чате со всей командой. И о проектах, которые поднимались из руин за полгода-год, которые факапились около трех лет «опытным тимлидом» с командой разработчиков. Ладно если бы это была случайность и один проект, но это разные проекты, и повсеместно особенно на фрилансе.
0
Тимлид
1) Управление: Разработкой управляет тимлид. Правила придумываются им. Обязательно
принимает в разработке активное участие.
2) Селекция: Лидом становится тот, кто первый зашел на проект или сам руководитель проекта
(друг-брат-сын). Конкуренцию в команде выигрывает тот кто безоговорочно поддерживает лида.
3) Планирование: Планирует спринты тимлид, спринтов может не быть, спринты могут быть
разной продолжительности, задачи могут появится внезапно в спринте, спринт может появится
внезапно, может быть несколько активных спринтов, команда не принимает участия в
формировании спинта, просто ставится перед фактом. Дата выхода продукта и обновлений не
поддается прогнозированию.
4) Факапы: в случае факапа выбирается жертва, ничего не решавшая до этого. Например,
выкатили жертве срочные баги перед релизом по чужому коду, не выпутался, не орел, причины
проблемы никого не интересуют.
5) Скорость разработки и кодовая база: скорость разработки и кодовая база ограничена
квалификацией тимлида. Все что тимлид не понимает отвергается или не принимается пока он это
не поймет. Зон ответвености нет, всем внушается что каждый ответственен за весь проект, хотя по
факту никто ничего ни решает, практикуются обязательные пулл реквесты для всей команды,
кроме лида, которые он жестко контролирует. Модульность кода часто отсутствует, все смешано,
и тесно взаимосвязано. (tightly coupled).
6) Поддержка: приветсвуются быстрые костыльные решения без истинного выяснения проблемы
и затрат времени на это.
7) Багофиксы: баги раздаются случайным образом, код фиксится и модифицируется часто не тем
кто его писал, постоянно тратится время на его изучение, дебаг и фикс без контекста задачи.
Атмосфера: гнетущая и нервозная. Работа идет в постоянном состоянии дедлайна. Срочные
задачи появляются неожиданно.
9) Работе нет конца и края или она может прекратится внезапно. Разработчик или без отпуска или
без работы.
Знакомые ситуации?
0
Давайте, я отвечу такой аналогией.
У меня есть велосипед — у него отвалилось колесо.
Он был покрашен — краска стала отходить.
Проехав 10 километров, он заскрепел, т.к. не был смазан, а после 20-ти километров появился люфт руля.
Вывод: все велосипеды — зло!
Так и вас: вы приводите нормальные поинты, только поинты эти берутся не столько от роли, сколько от того, как работу этой роли организовали и других внешних факторов.
0
только поинты эти берутся не столько от роли, сколько от того, как работу этой роли организовали и других внешних факторов
Эту работу как раз и организует лид, постоянно создавая команде проблемы. Если конечно в ней не джуны, ничего не понимающие, и не видевшие.
Все бы так, да в скраме так не забалуешь, там быстро все выводится на чистую воду), потому как в скраме открытые обсужения и абсолютная прозрачность, что лидам вообще не в масть (которым надо постоянно позиционировать свое менторство, и не дай бог в команде кто то появится, более сведующий, которой постоянно «дискредитирует лида» своими предложениями, и по-тихому убирается из проекта). Лид не нужен совсем, нет в скраме такой роли. Вот и в таких статьях и постоянно выдумывают чем же заниматься лидам. А аналогия не в тему и не логична, можно все что угодно приплесть и машину и ракету и холодильник и т.п.
Тимлид держится за место на проекте, но не за сам проект, он скорее завалит проект, чем согласится перейти на скрам, и ликвидировать эту роль.
0
Это ограниченное понимание роли лида, притянутое за уши опыта, через который вы прошли. Повторюсь: не стоит путать свойство функции со свойством исполнителя этой функции. Если, к примеру, вам только и встречались лиды, которые были «дискредитированы» более «сведущими», то это не значит, что все лиды такие
Лид не нужен совсем, нет в скраме такой роли.
Если с Скраме нет какой-то вещи, то это не значит, что она не нужна!
Если в Скраме нет роли лида, то это не значит, что никто не исполняет эту роль!
0
Круг замкнулся,
Расскажите, пожалуйста, что за нормальные проекты такие, чем отличаются от «ненормальных», и почему тимлиды на них еще и тормозить других начинают
Если с кадрами и управлением на проекте все печально, конечно «тимлид» нужен. Но имейте в виду, что появится побочка, в том, что кадры и управление не смогут улучшаться из-за ограничения в виде того самого тимлида.
0
Как говорится почувствуйте разницу
Скрам
1) Управление: разработка регулируется общепринятыми(в мире) правилами скрама, за которыми
четко следит скрам-мастер. Сам он может не участвовать в разработке. Или скрам мастер может
менятся как дежурный.
2) Селекция: по профессиональным качествам. На проекте здоровая конкуренция.
3) Планирование: планирование выполняется совместно всей командой (планирование спринтов,
спринты одинаковой продолжительности чтобы анализировать велосити команды и устойчивое
развитие продукта, всегда один активный спринт, новые задачи не втыкаются по мере
возникновения, а планируются на следующие спринты). При серьезном подходе можно
рассчитать выход продукта и обновлений.
4) Факапы: в случае факапа, идет детальный разбор ошибок и реальное выяснение проблемы,
предложения по улучшению (рефакторинг, декомпозиция) закладываются в следующие спринты.
5) Скорость разработки и кодовая база. Скорость разработки и кодовая база ограничена
совокупной квалификацией команды. Проект поделен на зоны ответсвенности. Каждый
разработчик отвечает за свой участок, в коде проекта обязательно четкая модульная архитектура
(loosely coupled). Практикуются перекрестные пулл реквесты для улучшения кода.
6) Поддержка: приветвуется рефакторинг, упрощение, разделение и инкапсулирование
сущностей. Выявлятся и устраняются причины багов.
7) Багофиксы: Баг забирает тот кто реализовывал задачу, вспоминает задачу или если надо быстро
находит таск и перечитывает контекст задачи.
Атмосфера: спокойная и продуктивная, задачи планируются заранее. В спринте есть время
сделать все качестаенно, подумать, поисследовать проблемы, переделать/улучшить по желанию.
9) Разработчик примерно понимает сроки окончания проекта и может планировать отпуск,
переход на другой проект или время на обучение.
0
Очень понравилась статья, ибо похоже на собственную жизненную ситуацию:
я тимлид в аутстафф команде разработки, и как раз-таки являюсь тем самым фронтэндом между руководством (в другом городе, общение скайп+почта) и нашей командой. Распределяю задачи, оцениваю возможности и личностные качества отдельных членов команды, помогаю с вопросами и принятиями решений (помогает бо’льший опыт взаимодейтсвия с дорабатываемой системой). Ну и заинтересованность повыше, конечно… В общем, очень хорошо Ваша концепция ложится на мои реалии, респект!
+1
Спасибо за отзыв, очень важно узнать, что теория попала в конкретный случай!
+1
И всё-таки остается загадкой: совершенствование процесса в команде — это основная или побочная обязанность тимлида? С одной стороны, команда сама должна вырабатывать «правила игры», но иногда для этого требуется «волшебный пинок».
0
«Совершенствование процесса в команде» — что вы имеете в виду?
Тимлид отвечает за то, чтобы команда справлялась со взятыми на себя обязательствами.
Чем эффективнее справляется, тем эффективнее деятельность самого тимлида.
Можно вообразить частный случай для иллюстрации:
Работа в паре с давним товарищем, днем вместе работают, ходят на дни рождения подруг/детей.
Один из них тимлид, причем это тимлидство практически не проявляется в работе — все обязанности давно явно или неявно распределены, взаимное доверие развито, оба знают в каких вопросах кто сильнее, лишь в некоторых случаях возникают споры, но оба заранее уже знают, чье мнение будет окончательным. Такое взаимодействие внутри команды — то к чему стремятся (должны по крайней мере) любые тимбилдеры, тут уже нечего совершенствовать. Можно подтягивать технические компетенции, не дать застрять в прошлом технологическом веке, но внутренние процессы команды отлажены до практического предела.
Когда людей в команде больше, знают они друг друга хуже, уровень компетенции разный, ответственность различается, возраст расходится, тогда задача тимлида усложняется, и наладить взаимодействие в приемлемый для проекта срок — задача тимлида, за которую он взялся исходя из каких-то своих соображений, когда принимал людей в команду.
Это и есть одна из задач тимлида, как тимлида, другая деятельность, такая как проектирование, уточнение требований и прочее сотрудник осуществляет от лица других ролей.
0
Тимлид — это такой человек, который знает абсолютно все о проекте, у которого можно спросить любую вещь и он ответит. Который имеет видение проекта как в целом, так и в деталях, обладает определенной интуицией в способе решения поставленных задач.
В любом успешном проекте есть такой человек, и не обязательно в IT: главный конструктор, ведущий инженер, etc… Если в проекте нет такого человека — это показатель обреченности проекта. Как бы мы ни старались развивать колаборационные навыки, идея и интуиция не масштабируются и не могут функционировать распределенно во многих головах сразу.
0
Статья большая, а все очень просто. Тимлин — это человек способный организовать команду на реализацию заявленного продукта. Все остальное словоблудее. Нужно будет и огород копать пойдет. ))
0
Я с вами не согласен. Возможно попытки формализовать что такое тимлид в разработке обречены на провал. Но то, что вы описали — это пипл менедмент.
Он должен суметь сделать так, чтобы каждый член команды справлялся с поставленными перед ним задачами. Для этого нужно, чтобы:
члены команды были согласны выполнять поручения,
достаточно компетентны для этого,
обладали достаточными ресурсами (в первую очередь — временем),
могли ужиться вместе.
В крупных компаниях этим занимаются пипл менеджеры. И это целая наука. Не нужно быть лидером, чтобы обеспечивать все эти пункты. Они в принципе не имеют отношения к лидерству.
Лидерство — в психологии процесс социального влияния, благодаря которому лидер получает поддержку со стороны других членов сообщества для достижения цели.
Вот и все. Тимлид — это человек, который в силу каких то причин (своей компетенции, позиции в компании или доверию менеджмента) получает поддержку от команды, что дает ему в руки инструмент влияния на эту команду. Этот инструмент влияния может быть потрачен на цели пипл менеджмента или на цели проектного менеджмента. Но это совершенно не означает, что тимлид автоматически становится пипл или проджект менеджером. Или должен им быть.
Конечно часто в компании тимлид может объединять разные роли. Но не надо придумывать новые определения для этого термина сужая его изначальные рамки. Так вы автоматически уходите от реальности.
0
Спасибо за ваше мнение!
Видимо мы живем в разных мирах, так как в моем я не слышал о специльно выделенной должности — people manager, которая подразумевает принятие на себя обязанностей тимлида. Как он существует, в команде или вне ее? Было бы интересно, если бы вы привели ссылку на вакансию или перечень требований в любой из компаний.
Возможно вы подразумеваете тех сотрудников, что существуют для решения задач найма и поддержания командного духа и т.п.? Или линейное руководство, в чьи задачи как раз и входит формирование команд, способных решать задачи проектов? Это — не тимлиды и своим наличием они не отменяют необходимости существования тимлидов в рамках непосредствнно команд разработки.
0
Я говорю о линейных менеджерах, к которым прикреплены люди. Которым непосредственно репортят. Которые решают проблемы мотивации сотрудников и их развитием в компании. Это не тоже самое, что проектный менеджмент.
Внутренние отношения в командах — это управление людьми. Управление людьми и лидерство — это не одно и тоже. Я понимаю, что можно легко взять какой то термин и начать придумывать для него определение. Вот только зачем?
В моем понимании если человек позиционирует себя как тимлид — значит от него ожидается, что он способен вызвать доверие команды и своим авторитетом повлиять на ее мнение для того, чтобы можно было решать проблемы управления людьми или проектами.
А менеджер (руководитель) как раз имеет компетенцию, для того, чтобы эти проблемы решать опираясь на доверие команды к лидеру.
Именно поэтому тимлид — это почти всегда самый опытный инженер для данного конкретного проекта для данной команды. Или самый ответственный. И редко так бывает, что тимлид обладает специальными знаниями в области управления людьми. Следовательно профессионально решать такие проблемы он не сможет.
Ну… я говорю о роли конечно, а не о человеке. На одном человеке может быть много ролей.
В командах профессионалов (не в какой то технологии, а в принципе) тимлиды обычно просто не нужны. Потому, что люди и сами могут согласовывать решения и работу. В таком случае ресурс лидерства-подчинения, предоставляемый тимлидами, просто перестает быть нужен для менеджеров. Если же команда согласовываться не в состоянии, то из нее выделяют лида.
Но какой то специальной профессии тимлид нет. Человек просто может быть тимлидом в данной конкретной ситуации. А профессия менеджера (который управляет людьми) есть.
0
Тимлид — это заблуждающийся мидл, у которого наконец-то, что то начало получатся в программировании, и он решил почему то управлять командой, тестированием, дизайном, кадровыми вопросами и т.п, а пм это допускает, в силу своей некомпетентности. Проектами должны управлять специально обученные люди, пм-ы или скрам-мастера.
-1
ПМы ничем не могут управлять потому что они не способны оценить сложность задачи, не способны понять что идёт не так, не способны это исправить и не способны нести ответственность и исправлять ошибки.
ПМы могут помогать тимлиду с кадровыми вопросами (если он сам не тянет) и с идеями по улучшению процесса (если они для этого достаточно компетентны).
Скрам-мастера — вообще люди, которых непонятно кто и зачем придумал. Я ни разу не видел процесса, в котором разработчики правда работают и при этом зачем-то нужен скрам-мастер.
0
Если вы что то не видели, это не значит что этого нет. Скрам-мастер входил еще 2017 году в топ самых высокооплачиваемых специалистов в штатах www.forumdaily.com/top-25-samyx-vysokooplachivaemyx-professij-v-ssha. Для того он и нужен, чтобы заказчик не тратил зря средства, а команда сфокусировалась на результате, и не деградировала и не затачивалась под знания тимлида (который зачастую технически не превосходит, других специалистов в команде), хороший скрам-мастер всегда может объяснить зачем он нужен. Сложность задач не нужно субъективно оценивать ака «тимлидом» (странным мидлом), для этого существует более точные техники типа scrum poker (и совокупное мнение участников команды).
0
Если за что-то платят — это ещё не значит что оно столько стоит. Любой человек, который умеет себя хорошо продавать получает достаточно много. Если у него при этом ещё и звучное название позиции — то тем более.
И насчёт «может объяснить» — да, именно поэтому мы так много и стоим. Я тоже могу объяснить зачем я нужен и почему кто-то другой не нужен. Люди с хорошими коммуникативными навыками очень хорошо проходят интервью и достаточно много зарабатывают. Это ни о чём не говорит.
А вот если у вас есть статистика о том, что «вот у нас две команды, одна с тимлидом, другая со скрам-мастером, команды одинакового уровня и по таким-то метрикам команда со скрам-мастером выигрывает» — вот тогда тут релаьно есть что обсуждать.
0
да статистика такая такая есть…, проекты просто факапятся, потому что тимлиды, становятся таковыми на проекте, просто потому, что они первые попадают на проект, и отбор остальных участников команды, идет уже не выше его компетенции, а так как тимлид держит и админские права на проекте гита или таск менеджера, то там даже овнеры сделать ничего не могут и дальше раскручиваются на деньги, пока не выдерживают и не разгоняют всех. Тимлид — ставит галочку в портфолио, что он «качественно там поработал», а проект затянулся и завалился, потому что команда плохая попалась, причем все специалисты сразу. Вот такая правда жизни. Не надо портить перспективного спеца(мидла или сеньера) и наделять его управленческими функциями.
Если за что-то платят — это ещё не значит что оно столько стоит.
Это да, если это частный случай, но не может статистика ошибаться по всем скрам мастерам.
Хочется идти в управление проектами, завязывай с программированием (не мешай другим), обучайся методикам эффективного управления (по мне так это еще сложнее чем программировать), и становись проффеcсионалом в своем деле. Но не надо и программировать, и управлять, и тестировать и админить и кадры искать, хотя для домашнего хоумпейжда, можно все это совмещать и быть «тимлидом».
0
В этой статье будет рассмотрена авторская модель (фреймворк) по переходу компании к системе управления на основе Agile-культуры и гибкой операционной модели.
Чем меньше размер компании, тем проще будет осуществить это преобразование. Компании с общим числом сотрудников до 10-15 человек обычно изначально работают в Agile-ориентированном подходе, поскольку все сотрудники полностью вовлечены в процесс, делают все что нужно вовремя и проактивно, и всем важен общий результат. У каждого сотрудника, вне зависимости от его должности в компании, есть внутренняя мотивация этот результат достигать.
При этом, когда штат компании начинает увеличиваться, компания, как правило, переходит к стандартной системе масштабирования по компетенциям, в которой сотрудники, обладающие определенными навыками и знаниями, составляют отдельную структурную единицу. Так, например, с наймом новых сотрудников маркетологи образуют подразделение маркетинга, разработчики подразделение ИТ, юристы юридическое подразделение, а сотрудники, отвечающие за операционный бизнес – например, департамент розничного бизнеса.
Такой подход к развитию компании, с одной стороны, позволяет оптимально управлять человеческими ресурсами и их загрузкой, с другой стороны, обезличивает бизнес-результаты в глазах простых сотрудников (исполнителей задач), уменьшает их вовлеченность в общее дело и ответственность за общий результат.
Agile-трансформация, по своей сути, является постепенной трансформацией культуры крупной компании, ее структуры и операционной модели в более гибкую и подвижную модель, поддерживаемую специальными процессными фреймворками, такими как Scrum [1], Kanban-метод [2], SAFe [3] или LeSS [4].
Цели, которые ставит перед собой компания от перехода на Agile-подход
C точки зрения руководителей компании, которая планирует осуществить переход в Agile-модель работы, трансформация должна отвечать следующим основным задачам (помимо собственно увеличения прибыли):
- Ускорение производственных процессов (например, скорость выпуска нового продукта или отдельных его новых функций, если это ИТ-компания)
- Повышение удовлетворенности потребителя за счет большего соответствия функций продукта, выпускаемого компанией, его (потребителя) задачам. А также за счет улучшения сервиса в точках контакта потребителя и продукта (например, розничная точка или веб-сайт)
- Большая мотивация и вовлечение всех сотрудников в конечный бизнес-результат компании.
Каждую из таких задач гораздо проще решать, если применять Agile-подход и соответствующие практики, разработанные за последние несколько десятков лет в Agile-сообществе (например, современный продуктовый подход LeanStartup [5]).
Примеры известных Agile-трансформаций крупных организаций
Обычно, когда в крупной компании речь заходит о серьезных изменениях культуры и операционной модели, у руководителей компании возникает резонный вопрос – а новых подход точно подойдет нашей компании, поможет ей, а не ухудшит текущую ситуацию?
И здесь самое время посмотреть на опыт индустрии, как конкретные компании в конкретном бизнес-домене уже применяют Agile-подход в своей работе.
Перечислим самые известные и цитируемые примеры Agile-трансформаций крупных организаций:
- Agile-трансформация банка ING (56 000 сотрудников, выручка 17.6 млд евро), проведенная консультантами из McKinsey [6]
- Agile-трансформация Сбербанка [7]
- Agile-трансформация Райффайзен Банка [8]
- Agile-трансформация ВТБ [9]
- Agile-трансформация Альфа-банка [10]
- Agile-трансформация Газпромнефть [11, 12]
- Agile-трансформация Северсталь [13]
- Agile-трансформация МТС [14]
Разработанный автором фреймворк Agile-трансформации
На основании моего опыта работы с крупными компаниями по переходу на Agile-модель за последние 12 лет я выработал универсальный, эффективный для применения в организациях различных сфер деятельности фреймворк Agile-трансформации компаний.
Как правило, первая основная фаза трансформации организации (а значит и ментальной и поведенческой модели людей, работающих в ней), проходит за 7-12 месяцев активного внедрения изменений. Одним из самых важных факторов успеха трансформации является искреннее понимание необходимости изменений и постоянная лидерская позиция в изменениях главы компании (CEО). Сотрудники будут меняться только в том случае, если они увидят, как изменилось поведение их лидера и как изменились требования и ожидания от их работы.
Рис. 1. Фреймворк Agile-трансформации (составлено автором)
Фреймворк Agile-трансформации, описываемый в данной работе, состоит из восьми ключевых стадий, через которые последовательно должна пройти каждая организация, решившая внедрить у себя Agile-культуру и подход. Рассмотрим каждую из этих стадий в отдельности.
1. Цели.
Любые изменения в организации должны начинаться с целеполагания, определения ясного и четкого результата, который мы хотим достичь в рамках трансформации. Самым лучшим на сегодняшний день подходом к целеполаганию является фреймворк Objective Key Results (OKR) [15], который я настоятельно советую использовать для описания важности изменений и формулирования ключевых результатов. Оцифрованные метрики, которые покажут прогресс в достижении цели сильно помогут сформировать нужную картину в головах руководителей и всех сотрудников, а так же в процессе внедрения изменений обеспечат возможность регулярной оценки продвижения по стадиям трансформации и результата внедряемых изменений. Еще одной задачей, которую необходимо решить на стадии целеполагания является оценка достижимости целей все командой, которая будет отвечать за трансформацию, а также выявление и анализ потенциальных рисков, с которыми может столкнуться организация в процессе перемен. Да, полностью нивелировать все риски компания никогда не сможет, но зная о них, можно будет вовремя заметить их возникновение и грамотно и быстро обработать.
2. Диагностика текущего состояния.
Задача этой стадии – сформировать как можно более подробное описание того, где мы сейчас находимся как компания, с точки зрения поставленных целей изменений. По сути, нам нужно описать точку “А”, в которой мы сейчас находимся и иметь возможность на следующем этапе Стратегии прочертить вектор в нужном нам направлении изменений. Диагностика может быть выполнена с применением любых подходов, но я рекомендую придерживаться фреймворка “4P” [16], в котором оценка производится по следующим областям (ниже я привел примеры вопросов, которые могут быть заданы):
- Продукты (англ. Products). Как устроена работа над основными продуктами компании? Какие подходы и фреймворки используются для развития продуктов? Какие инструменты и практики компания использует для лучшего и более глубокого понимания клиентов, их потребностей и задач, которые клиенты решают? Как происходит создание и валидация продуктовых гипотез? Каким образом и как часто собирается обратная связь с рынка по каждому из наших продуктов?
- Процессы (англ. Processes). Насколько текущая эффективность процессов в организации (в первую очередь, производственных), соответствует ожиданиям руководителей компании и рыночным условиям? В чем мы видим причины несоответствия? Какие из процессов требуется оптимизировать в первую очередь? Какой эффект эта оптимизация может дать компании?
- Люди (англ. People). Насколько вовлеченность сотрудников соответствует ожиданиям руководителей? Какие основные требования сейчас предъявляются к новым сотрудникам? Как происходит работа над повышением вовлеченности и мотивации? Какие проблемы взаимодействия имеются между руководителями и сотрудниками, внутри проектных и продуктовых команд (или отделов), а также на межкомандном (межотдельном) уровнях?
- Производительность (англ. Performance). На сколько текущая производительность в ключевых процессах отличается от целевой? Какие гипотезы у нас есть на сегодняшний день по причинам их возникновения? Какие данные у нас есть в подтверждение этих гипотез? Какие мероприятия по улучшению производительности уже были реализованы в предыдущие 3-6 месяцев?
По результатам диагностики организации мы получим полную картину того, где мы сейчас находимся, а наложение на эту картину целей позволит всем заинтересованными лицам увидеть и осознать необходимость проведения изменений. Важно подчеркнуть, что именно осознание необходимости и срочности (а также неотвратимости) изменений большинством ключевых сотрудников является одним из определяющих факторов успеха всей трансформации.
3. Стратегия.
К моменту перехода к стадии формирования стратегии у нас уже есть описание точки «A», в которой мы сейчас находимся, а также понимание, почему дальше нельзя без изменений. На данной стадии нам необходимо сформировать и описать вектор изменений, направленный в область «B», описанную нашими целями.
Рис. 2. Переход организации и текущего состояния в Agile-культуру
Важно понимать, что в контексте Agile-трансформации мы не можем описать конечную точку изменений, вот мы поменялись и теперь можно остановить этот процесс, мы уже достаточно Agile. Изменения – это непрерывный процесс выявления проблем, постановки целей и их достижения, поэтому целевое состояние следует описывать либо как некоторую область “B”, либо как вектор “B” — направление, в котором мы планируем вести изменения. Какой будет конкретная точка изменений, никто не знает и это зависит от огромного количества факторов, которые мы не в состоянии полностью контролировать.
Итак, первое, с чего следует начать в формировании стратегии изменений – это Видение, то есть наш “целевой” портрет как компании. Основываясь на этом видении и целях, следует сформировать стратегию их достижения, в которой будут описаны основные области, по которым необходимы изменения, детализированы цели по каждой из областей, описаны метрики, по которым можно будет произвести оценку достижения цели, а также приоритеты и временные рамки на каждую область изменений. При этом важно помнить, что Agile-поход – это не только новая операционная модель и новые инструменты, это еще и изменение модели мышления сотрудников. Поэтому в стратегии также должно быть предусмотрены изменения в ожиданиях от сотрудников на ключевых ролях, а также базовый перечень компетенций, на основании которых, HR подразделение осуществляет поиск новых кандидатов на работу в компании. Так, например, в Agile-компаниях важную роль играют soft-skills сотрудников – навыки работы в команде, самомотивации и развития, навыки получения и дачи обратной связи.
4. Общее видение.
Сразу после формирования стратегии изменений необходимо провести ее коммуникацию основной части ключевых сотрудников организации. Это позволит достичь сразу нескольких положительных эффектов:
- Сотрудники будут понимать, что происходит и будут меньше сопротивляться изменениям;
- Сотрудники будут ощущать личную безопасность в работе во время активных изменений, которые будут их окружать;
- Сразу найдутся те, кто больше остальных заинтересованы в изменениях и вовлечены в них. Помощью этих сотрудников компания сможет начать пользоваться уже завтра;
- Сотрудники будут понимать, в какой момент изменения придут к ним, как и когда им нужно будет активно вовлекаться в эти изменения и менять свой привычный уклад работы.
Даже одна сессия коммуникации видения изменений от руководителей способна существенно вовлечь большую часть сотрудников и снять риски отторжения изменений и сопротивления. Наилучший формат такой встречи – общее офлайн-мероприятие с двухсторонней коммуникаций и активным вовлечением сотрудников в обсуждение видения, целей и стратегии изменений.
5. Запуск изменений.
Переходя на данную стадию, нам необходимо создать новый управляющий орган внутри организации — Команду трансформации, задачей которой будет лидирование и управление изменениями, а также регулярная корректировка стратегии на основе обратной связи с разных уровней компании, получаемой по ходу трансформации. Хорошей практикой является создание такого состава команды трансформации, который бы включал в себя CEO, нескольких директоров подразделений, нескольких представителей среднего менеджмента и тех людей из организации, кто обладает мотивацией и внутренне готов лидировать в изменениях. При этом, в целом, не играет роли, на какой должности эти люди работают. Главная цель команды – быть драйвером и проводником изменений внутри компании.
Поскольку компания – это живой организм со множеством связей внутри, достаточно рискованно будет внедрять изменения сразу на широком фронте, заставляя большинство сотрудников принять новую культуру и правила работы одним днем. Для того чтобы минимизировать риски ухудшения ключевых показателей производительности организации и негативного влияния на эмоциональный фон сотрудников, в большинстве случаев внедрение изменений начинают с нескольких (как правило, 1-3) пилотных команд (англ. Lighthouse team). Задача команды трансформации в самом начале изменений показать, так называемые, «быстрые победы», когда за короткий срок можно достичь показательных результатов.
Таким образом, на этапе запуска изменений выбираются несколько небольших проектных команд, которым ставятся конкретные цели на короткий период в 2-3 месяца и осуществляется поддержка перехода этих команд на новые Agile-практики и процессы. Крайне важную роль играет вовлеченность всей команды трансформации в изменение операционной модели работы пилотных команд. В большинстве случаев именно непосредственное вовлечение представителей высшего менеджмента в работу пилотных команд дает последним возможность более быстрого принятия решений и устранения возникающих проблем, что положительно сказывается на мотивации к изменениям и общей производительности команды.
6. Сбор данных.
На данной стадии, через 2-3 месяца после запуска изменений, командой трансформации производится анализ эффективности новых подходов, процессов и практик, которые использовали пилотные команды. Как мы помним, на этапе запуска этих команд были поставлены определенные цели, которые команды должны были достичь. Как правило, такие цели бывают процессными (скорость выпуска, качество продукта) или продуктовыми (вовлеченность клиентов, повторное использование), но в некоторых случаях есть возможность устанавливать непосредственно бизнес-метрики (например, показатель выручки). В любом случае команда трансформации проводит анализ каждого из показателей, а также общего впечатления об изменениях и самом процессе работы, включая изменения в вовлеченности и мотивации сотрудников. Как правило, даже на таком коротком промежутке времени уже заметны существенные изменения в работе, которые привносят Agile-методики.
Помимо анализа ключевых показателей, важным аспектом сбора данных является фиксация и последующий анализ основных проблем (или дисфункций), которые возникали во время работы пилотных команд. К таким дисфункциям можно отнести использование микроменеджмента со стороны некоторых руководителей, недостаточно четкие цели для команд, отсутствие эффективных инструментов для работы, устаревшие корпоративные политики (регламенты) или, например, чрезмерно бюрократизированные отдельные процессы внутри организации. Для каждой организации конкретный набор дисфункций, выявленных на этапе пилота будет свой, поэтому команде трансформации на следующем этапе предстоит серьезная работа по выработке решений для устранения найденных дисфункций.
Здесь важно заметить, что Agile-подход сам по себе не является серебряной пулей [17] для решения проблем организации. Но он позволяет подсветить и четко указать на те проблемные моменты в компании, которые в текущий момент мешают достижению нужной производительности, гибкости организации, мотивации и вовлечения сотрудников.
7. Адаптация.
Данный этап является одним из самых сложных в процессе преобразования организации. Дело в том, что обнаруженные на этапе пилотных команд дисфункции, как правило, кроются глубоко в процессах становления организации или ее отдельного подразделения, поэтому, в большинстве своем, не имеют простых и быстрых решений. Здесь потребуется большой уровень смелости и вовлеченности каждого из участников команды трансформации в то, чтобы честно и открыто согласиться с наличием каждой из обнаруженных серьезных дисфункций, а также провести серьезный анализ причин их возникновения.
Рекомендуется анализ причин возникновения проблем исследовать с помощью одного из системных подходов к анализу, например, Fishbone-диаграмма [18] или наиболее простой инструмент “5 Почему” (англ. 5Why) [19]. Суть этих подходов в том, что причины возникновения тех или иных системных проблем не лежат на поверхности и не очевидны. Но могут быть обнаружены, если мы начнем пытаться выяснять, что является первопричиной возникновения проблемы. И уже тогда, понимая конкретные корневые причины, команда трансформации сможет выработать конкретные действия, направленные на устранение этих причин, тем самым закрывая и саму исходную дисфункцию.
Таким образом, суть стадии адаптации заключается в том, чтобы на примере, найденных во время “пилотов”, проблемных моментов, придумать способы реагирования на них — ведь при дальнейшем масштабировании изменений на всю организацию эти проблемы будут только усугубляться в масштабах. На этой стадии, также, имеет смысл внести официальные корректировки в описание видения и внутренней культуры организации. Описать и презентовать ключевым сотрудникам новые роли в организации (например, Скрам-мастер и Владелец продукта), новые ожидания от работы и взаимодействия сотрудников (здесь в основном, речь про самоуправляемые команды [20]). Одним из основных артефактов стадии адаптации является описание новых процессов и правил работы в стиле Agile (англ. Playbook), которое затем будет применяться при запуске следующих команд и масштабировании изменений на всю организацию. Обычно такое описание готовят внешние консультанты, работающие в компании над процессом Agile-трансформации, совместно с командой трансформации и внутренними Agile-коучами компании.
8. Закрепление новых подходов и культуры.
Одной из самых частых сложностей, возникающих в процессе agile-трансформации, является откат назад, когда новые процессы и правила работы не выдерживают натиска старой корпоративной культуры и, без должной поддержки со стороны команды трансформации, возвращаются в исходное состояние. Чтобы снизить данный риск, хорошей практикой является в короткий срок после завершения пилотных проектов перейти к активным действиям по масштабированию новых практик и новой культуры на всю организацию. Таким образом, компания официально принимает новые правила работы, и они становятся новой операционной моделью организации.
Можно выделить несколько основных стратегий масштабирования: по департаментам, по продуктовым направлениям, по операционным процессам. В моей практике наиболее оптимальным подходом является масштабирование изменений по продуктовым направлениям. Если посмотреть на любую компанию, можно выделить основные направления, генерирующие прибыль, например: продукты для юридических и для физических лиц, продукты на российском и иностранном рынках и так далее. Взяв отдельное такое направление, можно достаточно быстро и системно внести нужные изменения в правила и формат его работы, определить ключевые метрики для оценки эффективности изменений и оценить их. Ретроспективно оценить результаты и определить дальнейший вектор изменений в этом направлении, а также, если необходимо, доработать описание процессов работы компании (Playbook).
Интересным побочным эффектом такого формата внедрения изменений является то, что смежные подразделения будут так же, раз за разом, вовлекаться в новые правила работы и будут более готовы к изменениям, когда дело дойдет до них. Например, когда основное подразделение, в котором внедряется новый подход, решит, что ему нужно обновить политику работы с документами, потребуется вовлечение юридического отдела, что позволит передать в него часть новой культуры и практик работы.
Организация процесса работы команды трансформации
С точки зрения работы команды трансформации на всех этапах изменений рекомендуется применять Scrum фреймворк с его недельными итерациями (спринтами) для организации процесса работы, а именно:
- Еженедельно встречаться, ставить цели на ближайшую недели и планировать основные активности.
- Несколько раз в неделю (2-5) встречаться командой трансформации для того, чтобы оценивать прогресс в рамках недельного плана и поднимать к обсуждению обнаруженные сложности и проблемы.
- По завершению недели на общей встрече команды подводить итоги недели, делать оценку того, что удалось достичь, а чего нет, в том числе, вовлекая в это обсуждения прочих заинтересованных лиц компании (например, ежемесячно приглашать участников из совета директоров).
- После подведения итогов собираться участниками команды и проводить анализ эффективности работы команды, ретроспективу, задачей которой является выработка новых подходов и практик к проходящим в компании изменениям.
Компании России, которые применили этот фреймворк Agile-трансформации
В качестве примеров российских организаций, которые вступили на свой путь Agile-трансформации, основываясь на данном фреймворке изменений, являются: Газпромнефть, Банк Санкт-Петербург, Альфа-Банк, МТС и другие организации.
Достаточно большое количество информации по Agile-трансформации этих компаний и ее результатам находятся в открытом доступе в виде статей на различных интернет-ресурсах и выступлений на конференциях докладчиков, имеющих непосредственное отношение к проведенным изменениям.
Как проверить, что компания готова к Agile-трансформации
На основе своего опыта я рекомендую перед началом трансформации организации свериться по следующим двум пунктам:
- Компания понимает, что такое Agile-подход, как он работает и что именно компании на ее текущем этапе развития. может дать внедрение таких изменений. Это позволит всем вовлеченным на данном этапе сотрудникам выровняться по понимаю перед запуском изменений, а также снизит риск возникновения неоправданных ожиданий.
- Генеральный директор является непосредственным лидером инициативы Agile-трансформации, даже если изначальная идея пришла от кого-то из его сотрудников. Первое лицо компании готово первым идти вперед в изменения, а также вовлекать сотрудников непосредственно своим примером. Понимая, какое количество личного времени и энергии на это потребуется в течение активной фазы в следующие 1-2 года.
Если на сегодняшний день в организации нет уверенности, что оба перечисленных пункта выполняются, следует либо провести вводную рабочую сессию (обучение) для команды руководителей компании по Agile-подходу, либо принять решение о запуске одной-двух Scrum команд, которые потенциально смогут продемонстрировать руководству рост эффективности работы с применением Agile-практик и инструментов, а также большую вовлеченность и мотивацию сотрудников. После этого еще раз свериться с пунктами выше и принять решение о начале Agile-трансформации.
Совет руководителю
В заключение хочется еще раз отметить, что работа в стиле Agile – это не просто изменения в процессе и инструментах, но в первую очередь изменения в ментальной модели сотрудников, в их способе мышления, в изменении их ценностей и формате восприятия окружающего мира. А поскольку большинство людей не любят меняться [21], то подобные изменения нужно, с одной стороны проводить плавно и эволюционно, а с другой стороны своим лидерским поведением показывать окружающим, какое поведение от них теперь ожидается в тех или иных процессах и ситуациях.
Мой совет руководителю, который стоит на пороге применения Agile-подхода в своей компании, присмотреться к современному стилю менеджмента – Servant leadership [22]. Именно на основе него можно в самые короткие сроки и с минимальными рисками перевести организацию в модель работы наиболее эффективных, самоуправляемых продуктовых и операционных команд.
Agile — это семейство «гибких» подходов к разработке программного обеспечения. Agile зародился в ИТ-среде, но затем распространился и в другие сферы — от банковских структур до транспортных компаний. Считается, что Agile идеально подходит для молодых стартапов.
Тем не менее к этой методологии активно присматриваются большие традиционные компании, применяющие ее для отдельных продуктов или целых бизнес-направлений. Как гибкие методы разработки используются российскими корпорациями?
Собственным опытом применения гибких подходов в своей работе поделились с Rusbase компании «М.Видео» и «АльфаСтрахование».
Цели Agile
Российская торговая сеть «М.Видео» использует agile-методы в своей работе уже более двух лет. Руководитель управления по инновациям группы «М.Видео-Эльдорадо» Евгений Джамалов объясняет, что компания ставила перед собой несколько целей, обращаясь к agile-наставникам, в том числе это была проверка эффективности гибкой методологии. Так, в торговой сети по некоторым продуктам оставался невысоким показатель Time To Market. Чтобы сократить сроки и стоимость разработки в этих сегментах, руководители направлений решили обратиться за помощью к тренерам. Пилотная команда протестировала итеративный подход, сравнила приблизительно одинаковые по объему задачи, выполненные с использованием agile-методологии и традиционной для компании «модели водопада», и пришла к выводу: Time To Market сократился на 30%, а стоимость разработки продуктов — на 25%.
Гибкую методологию используют и в компании «АльфаСтрахование». По словам руководителя программы трансформации «АльфаСтрахования» Михаила Панкратова, внедрение гибких методов менеджмента в его компании преследовало три конкретных задачи:
- создание продуктов, которые нельзя эффективно реализовать при помощи других подходов;
- масштабирование ИТ-производства с сохранением гибкости и управляемости небольших команд;
- стимулирование инициативности сотрудников и делегирование принятия бизнес-решений на том уровне, на котором они возникают.
В результате «АльфаСтрахование» начала использовать гибкие подходы хотя и в различной степени, но по всем направлениям бизнеса.
Сам процесс внедрения agile-методологии в страховой компании включал в себя такие этапы, как аудит и первичное обучение команд, обучение владельцев продуктов, поддержка развития scrum-мастеров, вовлечение в процесс трансформации топ-менеджмента компании и обучение фреймворкам и agile-инструментам участников scrum-команд.
Применение Agile
Евгений Джамалов говорит, что с использованием методов Agile в «М.Видео» работают два крупных продукта — сайт и торгово-кассовая система. Так, интернет-магазин торговой сети на 100% создают команды, разделенные на части. По такому же принципу разрабатываются новые продукты для торгово-кассовой системы.
В 2017 году сеть «М.Видео» использовала итеративную разработку при реализации проекта снабжения продавцов торговых точек планшетами. Программисты должны были создать мобильное программное обеспечение, интегрированное со всеми системами компании, при этом перед ними стояла задача максимально быстро повысить производительность и эффективность бизнеса при растущих показателях продаж.
Над проектом работали небольшие группы, каждая из которых поначалу действовала самостоятельно. Затем участники проекта собрались вместе, чтобы объединить свои разработки. В результате все запланированные показатели по скорости и производительности проекта были достигнуты.
Евгений Джамалов отмечает, что сейчас 51% всех разработок в его компании реализуется с применением гибких методов scrum и kanban, и новые подходы затрагивают front и middle-end системы. При этом заметно трансформировались и ускорились основные бизнес-процессы компании (маркетинг, продажи, логистика), а по некоторым направлениям планы 2018–2019 годов были выполнены даже к середине 2017 года. В результате компания стала больше ориентироваться на продукт, и в ней появились специалисты, развивающие продукты и играющие роль связующего звена между бизнес-юнитом и разработчиками.
Результатом таких изменений стала переориентация аналитиков, разработчиков и тестировщиков на командную работу, в которой каждый специалист видит свою роль и несет ответственность за команду. При этом вопросы, ранее решавшиеся через электронную почту в течение двух-трех недель, теперь закрываются в течение дня.
Как правильно внедрять Agile в компании и из чего складывается стоимость внедрения гибких подходов?
Генеральный директор Capital VAST, консультант и бизнес-тренер Константин Савкин говорит, если руководство и сотрудники компании готовы к переходу на гибкие методы работы, тогда Agile будет работать в любой компании, где не требуется жесткая регламентация бизнес-процессов. Эта методология не подойдет для контроля над производственными процессами, но вполне может быть использована в менеджменте, маркетинге или продажах.
Инициаторам проектов, выбирающим между самостоятельным внедрением гибкой методологии и помощью консультанта или тренера, эксперт советует не забывать о том, что Agile — это подход, а не коробочный продукт или догма. Поэтому для внедрения этого метода руководителю компании или проекта достаточно будет изучить и понять его принципы и правильно адаптировать под конкретные задачи бизнеса. При этом agile-методология всегда остается максимально гибкой и адаптивной, а выбрать только между консультантом, тренером или единственным ответственным сотрудником компании для ее внедрения нельзя — это всегда будет совместная работа.
Стоимость внедрения Agile, по словам Константина Савкина, может иметь совершенно несоизмеримые пороги в разных случаях — от двух или трех книг, купленных, прочитанных и адаптированных проектным менеджером в своей команде до бюджетов в несколько сотен миллионов рублей для корпораций и крупных финансовых организаций.
При этом стоимость внедрения складывается из двух факторов. Первое — это обучение персонала. Для этого нужно найти человека, который сможет зажечь искру в глазах людей и рассказать о возможностях методологии. Второе — затраты бизнеса на запуск пилотных проектов и последующее внедрение подхода в масштабах компании.
Недостатки
Михаил Панкратов говорит, что использование agile-методологии, как правило, обходится дороже других подходов в менеджменте. Если компания в своей работе должна воспроизводить повторяемые процессы, тогда проще и дешевле, по словам эксперта, применять другие методы. Руководитель программы трансформации «АльфаСтрахования» отмечает, что внедрение Agile требует поддержки на всех уровнях, и если ее нет со стороны заказчиков, то такой проект не всегда рационально доводить до реализации.
При этом основными проблемами, с которыми могут столкнуться компании при внедрении гибких методов разработки, по мнению Михаила Панкратова, являются:
- отсутствие квалифицированных scrum-мастеров;
- отсутствие квалифицированных владельцев продуктов;
- сопротивление среднего менеджмента, не принимающего новые методы работы.
Евгений Джамалов отмечает, что его компания по-прежнему по многим направлениям продолжает использовать классическую «водопадную модель». При этом, по мнению эксперта, выбирая инструментарий, каждый раз нужно исходить из задач и обстоятельств проекта. Жесткой установки использовать только гибкие подходы в «М.Видео» нет. Компания использует гибкие методы только там, где их действительно можно применить и где есть смысл ускорять рабочие процессы.
По словам Евгения Джамалова, Agile не применим в тех случаях, когда работу над продуктом нельзя разбить на малые части. Например, если речь идет о старой системе, имеющей сложную архитектуру или большое «наследие» или если изменение одной из ее частей влечет за сбой изменения всех остальных. В таких случаях лучше работать с использованием традиционных методов разработки.
Фото: Unsplash
При этом, по словам Евгения Джамалова, внедряя в компанию agile-методологию, нужно помнить, что не все сотрудники смогут принять такой подход. Для разработчиков-индивидуалистов такой формат работы может оказаться неприемлемым. При этом кто-то будет по-своему или слишком буквально трактовать ценности agile-манифеста. Несмотря на то, что в этом документе выделен принцип «рабочий продукт важнее документации», достаточная документация всегда должна быть под рукой у сотрудников поддержки и храниться для «потомков», объясняет менеджер «М.Видео».
Кроме того, agile-вдохновители должны быть готовы к тому, что с началом применения в компании гибких методов и с появлением первых конкретных результатов им придется вносить достаточно много изменений в бизнес-процессы и подходы к разработке. В компании Евгения Джамалова, например, такими недостатками оказались слабый DevOps, отсутствие автотестов и CI/CD-инструментов.
Оправдались ли инвестиции?
Руководитель управления по инновациям группы «М.Видео-Эльдорадо» говорит, что затраты на agile-тренинги и трансформацию процессов в его компании окупились достаточно быстро. Стоимость разработок сократилась примерно на треть, а скорость работы по отдельным направлениям увеличилась почти в четыре раза.
Михаил Панкратов также говорит, что инвестиции в проект оправдались. Однако менеджер уточняет, что оправдались затраты не на тренинги как таковые, а на использование комплексного и системного подхода, включающего управление agile-коучами. В результате в компании смогли реализовать проекты, которые в принципе не получалось реализовать долгое время, вне зависимости от вкладываемых средств и привлекаемых подрядчиков.
Материалы по теме:
«Разработчики и менеджеры — как садовники»: 10 цитат из новой книги об Agile
Agile, scrum, kanban: в чем разница и для чего использовать?
«Даже лучшие бизнес-аналитики и маркетологи могут выдать только гипотезу. Поэтому появился agile»
Быть гибким, но не потерять банк: как работает Agile в кредитных организациях
Отдайтесь Agile-трансформации: как создать успешную Scrum-команду
Зомби не пройдут. Как выбрать Scrum-мастера для вашей команды
Как бизнесу адаптироваться к быстро меняющейся экономике и новым задачам? Этот вопрос стоит особенно остро для крупных компаний. Новые тенденции, глобальные перемены, сдвиги в конъюнктуре — оставаться на плаву в настоящее время это сложная, но выполнимая задача. Тем не менее, когда дело доходит до практики, у малого и среднего бизнеса есть существенное преимущество — они более гибкие и реагируют на изменения быстрее хотя бы из-за меньшего количества предприятий и сотрудников. Корпорации, в свою очередь, всегда отставали из-за масштабов. И все же, выход для больших компаний есть.
Большая компания также может быть гибкой, и Agile — та самая методология, которой под силу раскрыть этот потенциал. За десятилетие существования Agile в мире бизнеса его адаптировали исключительно средние и мелкие предприятия, особенно IT и высокотехнологичные производства. Крупные компании придерживались традиционного waterfall-подхода, пока совсем недавно самые прогрессивные из них не начали один за другим внедрять Agile, полностью или в определенных аспектах, и эти практики оказались успешными. Вот пара примеров таких организаций.
Agile в корпорациях — кейсы
Компания: Spotify
Бизнес: стриминговый сервис
Масштаб: > 2500 сотрудников и> 100 миллионов пользователей по всему миру
Кейс: Spotify необходимо было улучшить взаимодействие с пользователем, в частности, помочь им быстро найти музыку, которая им понравится, среди миллионов треков. Компания разработала алгоритм, который будет предоставлять новый список воспроизведения для каждого из подписчиков еженедельно, но они не могли проверить его в среде традиционного менеджмента. После определенного рассмотрения Spotify решил внедрить Agile, что позволило им успешно провести серию тестов и запустить Discover Weekly. Именно Discover Weekly привлекло так много новых пользователей, что в конечном итоге сделало Spotify крупнейшей корпорацией мира по потоковой передаче музыки.
Компания: Microsoft
Бизнес: технологии, компьютерное программное и аппаратное обеспечение
Масштаб:> 100 000 сотрудников
Случай: как только в компании Microsoft наступил период бурного развития, самой большой проблемой для них оказалась обратная связь — как с сотрудниками, так и с пользователеями. Это стало особенно очевидно, когда они запустили Microsoft Vista в 2007 году. После длительного периода исследований и тестирования руководство начало внедрять Agile в рабочий процесс. Это изменило правила игры, что позволило им выпускать обновления каждую неделю, а также регулярно получать фидбек.
Из примеров этих несомненно крупных корпораций вы можете ясно увидеть, что Agile можно внедрить в такие крупные структуры. А поскольку у каждая компания индивидуальна, универсального решения не существует. Тем не менее, мы можем выделить общие черты компаний, которые внедрили Agile. Давайте начнем с:
Особенности Agile
Ценность для клиентов
Поскольку предложение уже давно превысило спрос практически в любой сфере, чтобы оставаться на вершине, организации необходимо удовлетворять потребности клиентов и делать это быстро и профессионально. Повышенное внимание к клиентам должно стать отправной точкой корпоративной философии.
Разделите объём работ
В той изменчивой среде, в которой мы живем, единственный способ контролировать решение большой проблемы, — это разделить ее на более мелкие части и раздать ее гибким межфункциональным группам. Более того, это способ получить максимально релевантный фидбек как от работодателей, так и от клиентов.
Корпоративная перемена
Чтобы Agile действительно работал, он должен быть признан и принят в масштабах всего предприятия, а не только в IT. Это особенно важно для крупных компаний — они просто не могут допустить расхождения в производительности и философии между подразделениями.
Новое мышление
По сути, руководитель и менеджмент должны развивать совершенно новую культуру, предпринимательский настрой и гибкое поведение. Очевидно, что такое коренное изменение не может произойти сразу, поэтому настоятельно рекомендуется проводить тренинги и семинары по Agile — как общие для всех сотрудников, так и отдельные для отделов и команд.
Конечно, независимо от того, насколько вы подготовлены, редко бывает так, так что все идет по плану — вы то и дело будете сталкиваться с трудностями. К сожалению, вы не можете полностью защитить свою компанию от них — тем не менее, предупреждён это уже вооружён. Поэтому давайте рассмотрим
Риски Agile
Автономная работа
В основе Agile Framework лежит концепция автономии и расширения прав и возможностей каждой команды; все же переход от коллективной ответственности к командной и даже индивидуальной обычно труден для восприятия. Как заметил Микеле Слайгер, автор проекта «Bridge to Agility»: «Менеджеры-проектировщики оставляют за собой принятие решений и не контролируют членов команды». Вместе с тем члены команды не понимают своих ролей и не знают, как адаптироваться к ним. В результате вы, казалось бы, хотели дать своим подчиненным большую свободу, но на практике никто не чувствует себя свободным.
Что можно с этим сделать? Инициатива должна исходить от высшего звена руководства. Топ-менеджеры, которые дают больше полномочий менеджерам среднего звена, создают атмосферу независимости и расширения прав и возможностей гораздо лучше, чем тысячи руководств и памятных записок.
Несоблюдение принципов Agile
У каждой крупной компании есть свои особенности работы — некоторые практикуют экстремальное программирование, некоторые внедряют непрерывную интеграцию. Эти общепринятые корпоративные практики часто пересекаются или даже противоречат Agile. Хотя сам Agile очень гибок, в его основе лежит определенный минимальный набор артефактов, ролей и действий, которые следует оставить нетронутыми.
Если мы говорим о крупной компании, самым разумным решением было бы нанять Agile-специалиста, который будет регулировать все расхождения между практиками. Специалист по Agile проанализирует рабочий процесс и культуру, особенности производства и реализации, и найдет объективное решение о том, как сбалансировать Agile и другие организационные процессы.
Нежелание менять культуру
Недоверие, отсутствие ответственности и инициативы, страх — эти чувства в сердцах ваших сотрудников стоят между вами и успешным внедрением Agile. Если высшее руководство обычно более непредвзято, проявляет энтузиазм и более стратегически мыслит, то персонал обращает внимание только на то, что происходит, и какие изменения ожидают их в ближайшем будущем. Будьте готовы к подозрению, панике, негативным чувствам и никогда не используйте принуждение. Вместо этого запланируйте встречи с руководителями и специалистами Agile, чтобы каждый мог выразить свою обеспокоенность и получить ответы на волнующие их вопросы. Людям нравится, когда с ними разговаривают, и если вы вдохновите их следовать за вами, они пойдут.
Как реализовать Agile в крупных компаниях?
Если общая философия Agile одинакова, будь в любой компании, большая или маленькой, эта методология будет внедряться по-разному. На данный момент существует небольшое, но достаточное количество гибких методологий, ориентированных на конкретно крупные предприятия. SAFe и Scrum of Scrums являются наиболее распространенными из них, поэтому давайте посмотрим на них.
SAFe создает среду, в которой гибкие команды и принимающие решения сверху вниз встречаются и работают вместе. По словам его создателя Дина Леффингвелла: «SAFe продвигает основные ценности расширения прав и возможностей и децентрализации контроля, но не децентрализации всего. Традиционные модели централизованного планирования программ и микротехнического менеджмента остались в прошлом с SAFe. Эта практика расширяет возможности». Чтобы получить более практическое представление о SAFe, перейдите к нашей статье, где мы описали её подробнее.
Scrum of Scrums — это существенно другая методология, но в итоге она нацелена на тот же Agile. Она основана на понятии Scrum — практике разбивки разработки на мелкие итерации или спринты, что позволяет команде уделить внимание каждому аспекту разработки. Тем не менее, когда есть много Scrum-команд, возникает необходимость в объединяющей и облегчающей структуре управления, и это то, чем в основном является Scrum of Scrums. Чтобы узнать больше о методологии и о том, как она выполняется специалистами Polontech, перейдите по ссылке здесь.
Так что это все о том, с чем предстоит столкнуться большой компании, которая хочет адаптировать Agile. Если вы чувствуете, что не можете самостоятельно справиться с ситуацией Agile-трансформации, вы можете обратиться к специалистам по Agile из Polontech LLC.
ВРЕМЯ ПРОСМОТРА
1ч. 40 мин.
Есть два подхода к разработке крупных проектов. Классический, или каскадный — это механика, в которой заранее готовится громадное техническое задание, учитываются все мелочи, предсказываются риски и затраты. И только потом начинается разработка. В digital такой метод работает неэффективно — когда команда разрабатывает большой проект, невозможно спрогнозировать все риски и проблемы.
Неожиданности появляются не только из-за бизнес-процессов, здесь работает и человеческий фактор. Например, представители заказчика могут намеренно затягивать внедрение ПО, преследуя личные цели. Сбор требований на этапе аналитики тоже не дает стопроцентной точности — заказчики не расскажут вам все сразу. Плюс сейчас ПО требует мгновенной реакции на отзывы пользователей — подход с долгой тщательной подготовкой не работает.
Управление проектами в стиле Agile и Scrum — иной подход. В основе — итерации, небольшие задачи с минимумом функций. Можно разработать основные функции, запустить ПО и постепенно дополнять его.
Плюсы методологии:
- Нет нужды составлять длинное ТЗ — вместо этого формируется гибкий список задач на основе желаний клиента.
- Бюджет гибкий — если деньги закончились, заказчик все равно получит работающий проект, пусть и с меньшим количеством функций.
- Меньше бюрократии — нет нужды согласовывать сразу всю документацию по проекту, достаточно получить одобрение руководителя по одному вопросу. Разработка других задач в это время не прекращается.
Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.
Scrum — это метод управления проектами, он входит в философию Agile. Ключевое отличие от классической, водопадной схемы создания ПО заметно сразу — для начала разработки не нужно техническое задание.
Вместо проектного задания используется бэклог — список функций, требований к системе, желаний заказчика. В Scrum они сортируются по приоритету. Это живой документ, добавляйте в него новые задачи по ходу работы.
Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.
Не нужно прорабатывать и продумывать полностью все функции сразу. Все «хотелки» и то, что появляется в процессе, добавляются в бэклог. Решайте, что делать сразу, а что стоит отложить на следующую версию.
Scrum создавался в первую очередь для гибкости и ускорения разработки. Для этого появилась механика спринтов — весь процесс делится на отрезки, обычно от одной до четырех недель.
Как это работает? Команда забирает из бэклога часть задач. Каждая разбивается на максимально мелкие тикеты. Теперь нужно оценить время на задачу, и вот здесь проявляется особенность Scrum.
Дело в том, что люди плохо считают процессы в абсолютных величинах. Сложно сказать, сколько часов что займет. Поэтому в Scrum используется относительная оценка. За основу берется простая функция, которую все оценивают одинаково — например, понятно, что ее сделают за час. Остальные тикеты вычисляются так — «это мы будем делать раз в пять дольше по времени».
Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.
Ключевая идея — до тех пор, пока команда не забрала задачи на спринт, их можно бесконечно видоизменять в бэклоге. В разработку уходит согласованная часть. Каждый спринт — это небольшой релиз, в конце которого команда показывает работающую функцию ПО.
В идеальном мире на ключевые роли в scrum-команде назначаются люди, выращенные на проекте. Такой человек будет знать процессы изнутри, лучше ориентироваться в оценках и понятнее ставить задачи.
Product Owner
Cвязующее звено между командой разработки и пользователями. Этот человек собирает общую концепцию продукта из мнений заказчиков и других заинтересованных в выпуске ПО людей. Он формирует задачи и расставляет приоритеты.
Scrum Master
Член команды разработки, отвечающий за выполнение ежедневных процедур и за соблюдение интересов команды. Этот человек фиксирует дедлайны и начало спринта, добавляет оценки, отчитывается перед заинтересованными лицами об этапах проекта. Растите scrum-мастера внутри команды.
Команда разработки
Люди, которые непосредственно создают и тестируют код.
К разработчикам есть несколько требований:
- Как минимум один человек в команде должен понимать код, который написали остальные. Тот, кто лучше всех разбирается в теме проекта, становится куратором.
- Все совместно владеют кодом, понимают, как работает продукт.
- Команда стабильная и постоянная.
- Аналитики, дизайнеры — опционально, достаточно приглашать на отдельные тикеты.
- Scrum на удаленной работе возможен, но придется трудиться над эффектом присутствия.
У такого принципа формирования команды есть минус — сложно заменить неожиданно выпавшего человека. Но скорость разработки на практике все равно выше, чем у других подходов.
Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.
Контролируйте работу команды с помощью двух scrum-показателей:
- Focus Factor — коэффициент, который показывает, сколько задача должна была выполняться по плану, а сколько вышло в итоге. Так оценивается «концентрация» команды над проектом.
- Velocity — производительность. Поможет спрогнозировать количество задач, которые команда сможет взять в следующем спринте — в зависимости от количества готовых тикетов в прошлом. Velocity = Focus Factor * Оценка новых задач.
В Scrum от сотрудников требуется минимальная отчетность. Каждый день человек должен ответить на три вопроса:
- Что сделано вчера?
- Что будет сделано сегодня?
- Какие есть проблемы и препятствия для выполнения задач?
Задача руководителя — выяснить и устранить трудности, которые мешают разработчику добиться прогнозируемого результата. Для сотрудников это три-пять минут — ответили на вопросы, поставили оценки, разбежались работать дальше. Никаких решений или дискуссий.
В конце каждого спринта проводится ретроспектива. Команда встречается, озвучивает мнение, что в отрезке было хорошо, что плохо. Спросите у сотрудников идеи — что поможет им работать быстрее и эффективнее, что исправит проблемы. Запишите их в отдельный план — забирайте туда только те идеи, которые возможно сделать за следующий спринт.
Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.
На следующей ретроспективе обсудите идеи из плана, отсортируйте их по категориям «плохо» и «хорошо». Повторите процесс — получается ретроспектива на ретроспективу.
Формируйте организацию процесса постепенно. Разбивайте день — например, шесть часов люди работают по спринтам, два часа остаются на срочные и случайные моменты. Если все пойдет без неожиданностей, ничего страшного, продолжайте спринт, сделайте больше тикетов.
Первый спринт команда всегда «факапит», потому что слишком оптимистично смотрит на дедлайны и задачи. Второй — берет очень мало задач и делает больше. Третий — снова плохая оценка, но уже чуточку лучше. Потом все выравнивается. Это рабочий процесс.
Не затягивайте с первой версией продукта. Демонстрацию лучше проводить после каждого спринта — пусть даже релиз не пойдет к пользователям. Не копите внутри команды много функций — покажите их заинтересованным лицам и получите обратную связь. После — сразу измените бэклог.
В этом основное преимущество Scrum — гибко менять список задач во время разработки, не делать лишнего и не получать тысячи правок после завершения проекта, как в каскадной методологии разработки.
Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:
- Trello — подходит для маленьких проектов, быстро и удобно.
- Scrumban — есть разные доски, вложенные задачи и подзадачи. Удобно для средних и маленьких проектов.
- Jira — есть версионность, удобно для больших и долгих задач. Поддерживает массу типов разработки. Попробуйте, она вам понравится.
- Научиться вести бэклог и расставлять приоритеты.
- Проводить спринты.
- Формировать стабильную и постоянную команду, решать трудности, растить внутри группы scrum-мастера.
- Контролировать работу с помощью диаграммы сгорания проекта.
- Организовать работу — каждый день интересоваться делами команды, проводить ретроспективу и закладывать время на тикет с запасом.
- После каждого спринта демонстрировать проект.
- Изучить инструменты и найти самый удобный.
Теперь вы знаете основы Agile и Scrum и можете начать внедрять их в реальные проекты. Но для эффективной работы с командой этого мало — нужно уметь делать это осмысленно, знать тонкости методологий и не теряться в сложных моментах. Всему этому учат на курсе Skillbox. Одновременно с обучением сможете использовать полученные навыки в работе.