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

• Инструкции

• Водопад

• Гибкие методологии

• Ничего не понятно

Даже уже состоявшимся руководителям зачастую сложно перестроиться под новые обстоятельства и есть большой соблазн использовать ту методологию, с которой больше всего опыта. Я сам, еще 3 года назад, пытался любую задачу решить через фреймворки Agile, но наконец понял, что это не всегда самое эффективное решение. Теперь то я понимаю, что фреймворки Agile, это как кроссовер в мире автомобилей - он подходит 95% людей, на нём комфортно ездить по городу, он справится в легком бездорожье, да я сам на таком езжу. Но если цель — сэкономить на топливе, вам подойдёт гибрид. Если ваша страсть джип трофи, то рамный внедорожник. А если вы бизнесмен с миллиардным состоянием — майбах или роллс ройс и так далее.  Этот выбор обоснован вашими целями и ограничениями.

Теория

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

В принципе, я всё показал и рассказал. Конец :)

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

Простая или сложная задача?

Для начала давайте определимся, простая она или сложная. 

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

Маркеры простоты:

• Вы до мельчайших подробностей знаете как ее сделать

• Вы можете обучить делать эту задачу "свою маму" за короткий срок

• Подробная инструкция помещается на А4 крупным шрифтом

• Предполагается большое количество повторений одних и тех же действий

• В решении участвует 1-2 человека

Примеры

Сначала потренируемся на "котиках", жизненными примерами простых задач являются:

• Вынести мусор

• Заказать такси для поездки в магазин

• Сварить пельмени

При этом есть очень похожие задачи, но на самом деле они зачастую не простые

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

• Съездить на машине до магазина.
  Кажется что может быть проще? Но для этого необходимо, чтобы у исполнителя были права на машину, а если их нет, то необходимо их сначала получить. А если есть права, то не факт, что есть машина. Таким образом это пограничная задача - после проведения анализа, мы выясняем есть ли права и машина и если да, то это простая, если же нет, то сложная.

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

Если говорить о задачах IT подразделения, то примерами простых задач являются:

• Передвижение задач по статусам на доске JIRA

• На основе обращения клиента завести тикет в JIRA

• Процесс согласования внедрения новых фич

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

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

Понятная или непонятная?

Маркеры понятности:

• Задачу можно полностью описать по SMART.
  Причем без исключений, не 2,3,4 фактора, а все 5. Обязательным признаком является формулировка результата без оценочных прилагательных типа хорошо, никогда, ужасно.

• Вы уже делали полностью аналогичную задачу.
  Учтите, что полностью, это значит полностью)

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

Примеры

Как и в прошлый раз рассмотрим жизненные примеры, примерами понятных задач является:

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

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

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

К непонятным задачам относятся:

• Научится водить машину.
  Если мы не говорим о получении прав, а о самом навыке вождения, то зафиксировать конечную цель мы не можем. Любая цель вида “каждый день рулить не менее 2 часов в течении месяца и отсутствие аварий” не говорит о приобретении навыка.

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

• Нарисовать красивый автопортрет.
  Красивый - понятие субъективное, если не верите, что просто попробуйте. Конечно же если вы не профессиональный художник))

Если говорить про ИТ, то классическими примерами понятных задач являются:

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

• Разворачивание сети и рабочих мест для десятого по счету филиала.
  Задача все еще сложная, но при этому опыта достаточно, чтобы она стала понятной.

• И… Я честно размышлял 15 минут и не смог придумать еще один пример. Чем больше опыта я получаю, тем больше нюансов я замечаю в задачах и тем менее похожими они кажутся.

Самый простой пункт - непонятные ИТ задачи:

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

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

• Решить баг.
  Они часто разные, возможно что в разборе будет участвовать несколько команд, всегда всегда работают чтобы стандартизировать разборы, но баги всегда разные и заранее предсказать “как пойдет разбор” на грани невозможного.

Выбор методологии

Простая и понятная задача

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

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

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

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

Сложная, но понятная задача

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

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

• Команды заранее знают, когда они от них что-то потребуется

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

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

Сравнение с другими методологиями:

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

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

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

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

Сложная и непонятная задача

При достижении линейными сотрудниками уровня middle все больше и больше решаемых задач будет находится именно в этом квадрате. Лучшим выбором будет agile (Scrum или KanBan мы рассмотрим далее). К плюсам относятся:

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

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

Что не так с другими методологиями:

• Инструкции.
  Нельзя придумать инструкции для то, что мы не понимаем. Это просто невозможно

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

А scrum или kanban?

Маркеры выбора:

• Какие задачи на команде преобладают - внешние или внутренние.
  Примером внутренней задачи может быть разработка новой фичи - ее придумал владелец продукта, обсудил с командой, все побежали делать. При этом прилетающие баги являются внешними срочными задачами. Примером преобладания внешних задач является работа выделенной команды поддержки, задачи для которой заводят пользователи системы, которые не являются частью команды поддержки.
  Если внешних срочных задач достаточно много, то scrum противопоказан из-за того, что спринты будут постоянно разрушаться, если нет, то скорее всего больше подойдет scrum, но kanban также допустим. “Лучше”, так как scrum дает большую предсказуемость, зачастую больше вовлеченности для сотрудников (командные практики в первую очередь для scrum работают), понимание цели для команды (vision продукта), как следствие это повышает эффективность команды.

• Сколько требуется на оценку задач.
  Задачи “добавить интеграцию с чатом в приложение”, “хочу нажать на кнопочку и чтобы вау было” и так далее не поддаются экспресс оценке, зачастую даже субъективную оценку дать тяжело без доп анализа. При этом задачи "Собрать логи пользователя", “переустановить windows”, “Сформировать ежемесячный отчет” вполне могут быть оценены достаточно быстро.
  Если большая часть задач поддается экспресс оценке, то kanban будет хорошим выбором, так как легко управлять leadtime, WIP будет достаточно прогнозируемым, церемонии scrum могут быть излишними и не приносить ценности.
  Если же задачи требуют доп анализа, то с высокой долей вероятности kanban не подойдет, так как вы не сможете равномерно распределять нагрузку по ролям, она постоянно будет меняться, ваши метрики постоянно будут давать сбои, так как leadtime будет постоянно разный и главное непредсказуемый из-за неминуемых ожиданий. Исключением может быть, когда любая задача делается одним человеком и не передается от роли к роли. Это нивелирует почти все минусы, даже метрики придут в норму, так как задержек не будет. В таком случае scrum будет лучшим выбором. Сложность оценки не является помехой, так как между предпланированием (PBR, Grooming) и планированием есть время на оценку, если задача слишком сложная, то ее можно декомпозировать на несколько спринтов и так далее. 

• Что делать если много внешних срочных задач, которые невозможно оценить и требуется несколько ролей для решения проблемы?
  Во всех пограничных случаях best practice не существует, поэтому просто опишу, как действую я. Для начала необходимо постараться свести это к одному из понятных сценариев. Сделать из срочных задач “не срочные” (на горизонте спринта) как правило легче, так же я все таки больше люблю scrum, так что сначала пытаюсь сделать именно это. Необходим анализ и ретроспектива по достаточно большой выборке с ответом на всего лишь на один вопрос “а можно ли было предусмотреть эту задачу или взяться за нее в следующем спринте?”. Как ни  странно чаще всего проблема лежит либо в недостаточном понимании владельцем продукта своей роли и более плотное взаимодействие с внешним источником задач позволяет получать информацию заранее, с такой же частотой бывает, что команда не умеет оценивать задачи и сама постоянно срывает спринты, поэтому владелец продукта срочные задачи вставляет в текущие спринты, чтобы как можно раньше все таки их сделать. Тут сначала выравниваем, чтобы команда соблюдала обязательства, потом с владельцем работаем, чтобы он вставлял задачи в следующие спринты. Но это почти невозможно сделать, если например мы смотрим на 2-3 линию поддержки, в таких случаях лучше пожертвовать метриками и начать с KanBan, с помощью регулярных каденций, зачастую можно процесс сделать достаточно оптимальным.

• Задачи внутренние, но достаточно стандартные и легко оцениваемые?
  Не думайте и берите Scrum, на столько легко запуска команд у вас больше никогда не будет :D А если серьезно, то можно использовать и тот и другой подход, они будут приносить свои плюсы, решите что для вас важнее.

Итак, когда мы разобрались scrum или kanban.

Хаос

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

Пришел начальник и сказал ”да когда ты уже будешь работать нормально”

Такую задачу в принципе невозможно описать, ни один из параметров определить.

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

1. Сделай что-то

2. Проанализируй результат

3. Придумай новое действие

Данные итерации призваны прояснить ситуацию и перевести задачу в один из других квадратов.

Давайте рассмотрим задачу выше на нескольких кейсах.

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

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

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

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

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

Заключение

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

1. Задача простая и понятная? Инструкции

2. Вы уже делали идентичную задачу минимум 2 раза? Водопад

3. Вы можете задачу полностью описать по SMART? Водопад

4. Вы можете по SMART описать 2-4 критерия? Agile

   1. Задачи рождаются внутри команды? Scrum

   2. KanBan

5. По SMART вы можете описать максимум 1 критерий, но это не точно. Ну что ж, вы в квадрате хаоса, начинайте как можно отчетливей анализировать каждое свое действие и перестаньте планировать “на будущее”

Спасибо огромное что дочитали до этого момента, надеюсь информация была полезна и интересна!

Bonus. Интересные факты

Все по кругу

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

Возьмем стандартную задачу - разработать новую фичу. Изначально это у нас сложная и непонятная задача, начали ее делать по Scrum. После декомпозиции, внутри одной команды, на один спринт будет применен водопад, когда пройдет аналитика, разработка, тестирование, внедрение. Внутри каждого этого действия будет применен ряд инструкций - передвигать задачи по доске, пройти чек-лист перед внедрением, запустить ci/cd pipeline. Но если вам не повезет, то после демо стейкхолдер скажет “это вообще не то что я хотел” и вы выпадете в квадрат хаоса)))

Я люблю agile за гибкость (тавтология конечно)), мы не замечаем как подстраиваемся под возникающие подзадачи и автоматом начинаем использовать правильную методологию.

Работа с аутсорсом

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

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