Здравствуйте, уважаемые подписчики и гости канала!
Итак для начала - что такое постановка задач по SMART, лучше всего ответит Википедия. Если вкратце - это такая схема постановки задач при которой задачи должны получаться:
- конкретными - в задаче описана конкретная область для улучшения
- измеримыми - количественная оценка или что-то, что покажет прогресс по задаче
- назначаемыми (достижимыми) - у них должен быть один конкретный исполнитель)
- реалистичными - с описанными конкретными результатами, но чтоб это не было Нью-Васюками
- осязаемыми (связанными со временем) - т.е. с понятными реальными сроками выполнения
Много букв, согласен. Раньше у меня в голове почему-то это все никак не могло уложиться в голове и стать привычкой при постановке задач, но потом я посмотрел выступление Александра Афенова Трудно быть Колей: теория и практика knowledge sharing в Lamoda и все встало на свои места.
Короче, есть вариант попроще SMART, с которым вполне можно успешно и не затратно по времени работать. Его как по мне проще запомнить и он понятнее, хотя суть вообще не меняется. У нас в команде мы уже взяли его на вооружение и я вижу отличные результаты - задачи стали сильно понятнее. Даже когда к задаче возвращаешься через время она не вызывает дискомфорт в плане того, что ты вне контекста и забыл что-то, что надо бы помнить для этой задачи.
Why, What, DOD
В любой задаче в описании должны быть заполнены следующие блоки:
Why (почему мы хотим сделать задачу)
What (что именно хотим сделать)
DOD (definition of done) список критериев успешности выполнения. Именно список, а не "проза" в виде простыни связанных предложений.
Подробнее разберем каждый блок, но начнем с того, что Why и What по сути являются скелетом задачи и не должны содержать мутных или длинных формулировок. Любому человеку суть задачи должна быть ясна после прочтения только этих двух блоков. Все подробности, нюансы, на которые стоит обратить внимание, обязательные к проверке, использованию штуки, запрет на что-то убирается в DOD.
Пример будет состоять из Epic (длинная задача не на один спринт, по сути подпроект) и одной задачи в нем.
---------
Epic: Перевод UI на ReactJS
Why: Поддержка LTS версии AngularJS кончается 21 декабря 2021 года, у нас весь проект написан на нем и проект имеет большую кодовую базу. Если мы не перейдем на другой фреймворк, то рискуем полной или частичной неработоспособностью нашего сервиса из-за обновлений браузеров, которые могут что-то непоправимо сломать. Нужно уже сейчас переходить на новый UI фреймворк, так как это очень трудоемкий процесс и нам нужен запас по времени. https://docs.angularjs.org/misc/version-support-status
What: Сейчас самым разумным видится перевод на React ввиду его гибкости, удобству и популярности у разработчиков, что поможет проще искать людей, а так же наличию гораздо большего количества готовых компонентов, по сравнению с Angular (2+).
DOD:
- Работы нужно выполнить так, чтобы расширять компоненты меты можно было без перекомпиляции и сборки ядра. Видится это как подключение через конфигурацию js и css заранее скомпилированных в отдельном репозитории файлов UI компонент.
- В процессе выполнения задач находить решения, которые не будут останавливать разработку UI из-за "переписывания всего" или сразу крупных частей на reactjs
---------
Задача: Сделать прототип кода, который позволит подключать react компоненты в ui для постепенного переписывания на ui react
Why: У нас много кода для ui, мы не можем остановиться и разрабатывать его "с нуля" на react
What: Надо найти рабочее простое решение для того, чтобы уже сейчас можно было подключать простые компоненты интерфейса на reactjs
DOD:
- Решение может не включать поддержку рендеринга angularjs компонентов в новых реакт компонентах (React -> AngularJs -> React).
- на react должен быть переведен компонент me-input text и там должна работать валидация и отключение валидации при рендере опционального lego
- компонент проверен рендерингом в me-lego-list
- вывод информации о пользователе в верхнем меню переведен на react
- angular 2 bootstrap отключен (так как если это не сделать, то мы очень сильно добавим времени на старт приложения и объем загружаемого кода)
---------
Очень надеюсь, что вы уловите суть - вся техническая требуха в DOD по пунктам, а не сплошным монолитным текстом. Why, What жестко разделены и отвечает каждый за свое. Прям принцип единой ответственности в деле ;)
Пример
Далее я приведу пример того, как часто ставятся задачи в проектах, почему это плохо и как предлагается их менять.
Текст задачи: "Вывести красную кнопку Купить справа от названия товара."
И ... часто это в принципе вся задача, ну может еще скриншоты со стрелкой, указывающей куда надо поместить кнопку.
Проблемы: зачем кнопка в данном случае мы можем догадаться, но почему именно красную и почему и именно в этом месте? Какой группе пользователей это потенциально поможет? Где ссылка на обоснование этого? Почему вообще она нужна, ведь уже есть другая - может она не работает хорошо, но тогда, где отчет на сколько плохо работает та, что есть?
Короче, тут через время никто не поймет предпосылок. Хорошо, если менеджер имеет хорошую память, но если нет или он уволится? Хуже всего становится именно проекту. Тут явно надо начать хотя бы с Why.
А вот как следовало бы поставить такую задачу, чтобы всем все было понятно и программист бы чувствовал важность задачи наравне с менеджером, а не относился к этому как с самодурству или типа того.
Название задачи: Вывести дополнительную кнопку Купить на странице товара справа от названия товара
Why: Исследования вебвизора показали, что пользователи, с не высоким экраном не всегда скролят вниз до деталей товара и не видят кнопку Купить. Поэтому решено провести тестирование с выводом дополнительной кнопки.
What: Справа от названия товара вывести стандартную красную кнопку "Купить", которая бы открывала стандартное модальное окно начала покупки.
{СКРИНШОТ СО СТРЕЛКОЙ НА НУЖНОЕ ПОЛОЖЕНИЕ}
DOD:
- Обязательно проверить адаптивность верстки на мобильных телефонах, так, чтобы кнопка тоже была видна
- Кнопка не должна перекрывать название товара
- Кнопку реализовать малыми силами, так как возможно, ее нужно будет убирать, если тест будет неудачный
+ Приложить к задаче ссылки и скриншоты с вебвизора на отчет по проблеме
---
При такой постановке задачи она будет понятна даже junior разработчику, особенно, если тимлид приложит в тело задачи, а не в комменты ( в jira это есть) ссылки на storybook (пример использования) с красной кнопкой.
Если вам понравилась эта статья, то возможно вам будет интересна и моя статья про принципы принятия решений в команде.
---
А на этом всё, спасибо за внимание!
Подписывайтесь на канал, ставьте лайки, оставляйте комментарии - это помогает продвижению в Дзене.
Кроме этого:
Подписывайтесь в Telegram: https://t.me/lets_goto_it
#тимлид #teamlead #разработка #management #jira #постановка целей #постановка задач