Настольная книга тимлида разработки ПО

Качество постановки задач

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

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

Методики постановки задач:

— S.M.A.R.T. является аббревиатурой, где каждая буква означает критерий эффективности поставленных целей или задач.

— Specific — (конкретный) — нацельте на конкретную область для улучшения

— Measurable — (измеримый) — дайте количественную оценку или предложите показатель прогресса

— Assignable/Attainable — (назначаемый/достижимый) — укажите конкретного исполнителя

— Realistic — (реалистичный) — опишите, какие результаты могут быть реально достигнуты при наличии ресурсов

— Time related/Tangible — (связанный со временем/осязаемый) — укажите, когда может или должен быть достигнут результат

— User story (пользовательские истории). Если говорить про Agile разработку, то пользовательские истории рекомендованы как наиболее простой и понятный заказчику способ. Но вместе с простотой появляются проблемы с невыявленными требованиями. Предложено несколько формул пользовательских историй:

— Я как <Роль> могу <Функционал>, чтобы <Получить ценность>

— Для того чтобы мне <Получить ценность> как <Роль>, я могу <цель/возможность>

— Как <Кто> <Когда> <Где> я <Хочу>, потому что <Причина>

— К пользовательским историям и не только часто применяется I.N.V.E.S.T. метод

— Independent (независимость) — Старайтесь избегать создания задач, которые зависят друг от друга

— Negotiable (обсуждаемость) — задачи не являются формальным контрактным обязательством или требованиями

— Valuable — ценность для пользователя и покупателя

— Estimable (оцениваемость) — разработчики должны иметь возможность оценить размер задачи

— Small (компактность) — от размера задачи зависит очень многое, слишком большие и слишком маленькие задачи сложно оценивать

— Testable (тестируемость) — подтверждением того, что задача разработана успешно, служит удачное прохождение тестов

— DoD (Definition of Done) — критерий готовности, некий формальный набор работ/мероприятий, свидетельствующий о законченности задачи. В этот список могут попасть автотесты, документация и проведено ревью. Набор необходимых условий для решения задачи.

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

— Технические задания по ГОСТу или нет — ёмкие опросники со множеством вопросов, которые раскрывают перечень различных требований.

— Есть еще некоторый набор интересных подходов CLEAR, PURE, CPQQRT

Какой же метод выбрать? В чем компромисс?

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

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

— Задачи, имеющие высокую ценность для бизнеса

— Задачи, ошибка в которых будет дорого стоить для бизнеса

Методы оценки задач, риски

Зачем оценивать задачи?

— Для планирования и понимание того, когда и какой функционал может появиться

— Для оценки экономической целесообразности реализации этой задачи

— Для оценки эффективности работы команды

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

Как происходит оценка:

— Ознакомление с требованиями задачи, уточнение вопросов.

— Проектирование решения, валидация спроектированного решения.

— Декомпозиция спроектированного решения.

— Оценка сложности и объема исполнения, а также рисков, связанных с реализацией и процессом.

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

Оценка НЕ РАВНО (#=) срок реализации. Оценка — это длительность выполнения задачи. Срок реализации — это результат процесса планирования оцененных задач.

Единицы измерения оценки задач:

— Человеко-часы или человеко-дни, реже недели или месяцы

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

— Story points — измеряют усилия, которые нужны, чтобы выполнить элемент Бэклога Продукта или любой другой отрезок работы. Сами по себе эти количественные оценки не важны. Важно то, как оценки разных элементов соотносятся друг с другом. История, которой присвоено значение 2, должна быть вдвое больше истории со значением 1 и соответствовать двум третям истории со значением 3.

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

— У разных команд будет разный размер Story point. Не стоит приводить их в соответствие без особой необходимости.

— Для ориентации команды на смежные величины, можно делать отсылку к конкретной задаче, которая была оценена в Isp.

— Без оценок

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

Существуют различные техники оценки задач:

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

— Диаграмма сходства (Affinity Mapping) — объединения схожих по трудности/объему/рискам задач в группы.

— Дерево декомпозиции — классическое разбиение задачи на части и их оценка.

— Сортировка задач — упорядочивание задач по шкале времени.

Планирование и декомпозиция задач

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

«Любой план — это ложь!», сказал мне как-то топ-менеджер Zara в процессе автоматизации их склада. Но зачем люди этим занимаются? Выстраивание планов — это поиск, попытка привести действия команды к наиболее оптимальному получению результата.

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

Обычно необходимо ответить на вопросы — какие задачи будут решены за следующую итерацию (спринт) или когда будет завершен проект?

Планирование проектов — это отдельная область, описанная в РМВОК, Prince2 и других гибких методологиях. В основном такое планирование опирается на:

— выявление задач

— нахождение и выстраивание параллельной работы

— нахождение зависимых задач и решение задач критической цепи

Планирование проектов производится с помощью Диаграммы Ганта.

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

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

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

Делегирование и эскалация

Делегирование — процесс передачи части функций другим членам команды.

Принципы делегирования:

— ожидаемые результаты

— обозначить ответственность

— наделить необходимыми правами (всестороннее делегирование, но без избыточных прав)

— делегирование лицу, имеющему необходимые компетенции

— своевременность делегирования

— отсутствие конфликтов по части ответственности

— поддержка при выполнении функций

— возврат полномочий (обозначить время/событие и процесс)

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

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

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

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

Шаги эскалации в проектном управлении:

— Проинформировать вышестоящее лицо, имеющее полномочия решить проблему

— Проанализировать причины проблемы и ее потенциальное влияние

— Разработать несколько альтернативных решений проблемы и оценить их достоинства и недостатки

— Описать ситуацию вышестоящему лицу, с вариантами решения и собственными рекомендациями

— Объяснить последствия несвоевременного решения проблемы

— Задокументировать результаты эскалации и зафиксировать извлеченные уроки

Повседневный контроль задач

Для разных процессов повседневный контроль задач будет отличаться. Так или иначе он сводится к:

— получению сводной информации по прогрессу задач

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

— решению проблем и задач

Что может дать сводную информацию по прогрессу?

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

— Для итерационных процессов применяется диаграмма сгорания

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

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

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

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

Автоматизируйте повседневную работу с помощью ботов, которые напомнят сотрудникам о:

— Зависших задачах

— Актуализации статусов, оставшемся времени по задачам и дотировании затраченного времени на задачи

— Текущих метриках спринта, показателях эффективности

Прием результатов

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

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

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

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