Нам дают задачи и ставят сроки. Иногда сроки не реалистичны. Возможная причина — задачу не проектировали, не разбивали на этапы. Сложно установить сроки выполнения, основываясь только на интуиции и опыте.
Мне, как разработчику сайтов, такие задачи попадаются. Сроки на эти задачи устанавливаются исходя из требований бизнеса. Поделюсь опытом — как в условиях узких сроков с успехом удавалось реализовывать требования бизнеса.
Привожу советы, которыми руководствуюсь сам и которые меня ни раз выручали. Каждое утверждение требует обсуждения, осмысления и критики.
Тон статьи кажется категоричным. Сразу же извиняюсь за это. Для краткости опустил фразы “я думаю”, “я полагаю” и проч.
Поделюсь опытом на основе примера. Придумаем же следующую задачу. Цифры и сроки условные.
Разрабатываем сайт e-commerce, который продает детские игрушки. Оплата только наличными. Реализовываем оплату безналичными с помощью:
- PayPal;
- Yandex.Money;
- QIWI Wallet;
Менеджер установил срок — неделя.
Вы покопались в готовом коде, изучили архитектуру, пораздумывали над этими требованиями. Вспомнили, что на нас висит еще 5 задач, которые никто не отменял. И осознали, что в установленные сроки вам не справиться.
Вы подошли к менеджеру, объяснили ситуацию. Менеджер ответил так:
- Задачи срочные, успейте сделать
- Ок, я приостановлю 2 задачи. Остальные 3 задачи выполняйте параллельно
- Ок, я продлю срок этой задачи на 1,5 недели
Эти варианты вас не устраивают. Времени не хватит. Вы оказались в тупике и задумались о таких решениях:
- придти на работу пораньше.
- задержаться на работе подольше.
- Вы и так постоянно задерживаетесь, задерживаться придется в 2 раза дольше.
Как же быть?
Тут поможет книга Стивена Р. Кови «7 навыков высокоэффективных людей»
- Будьте проактивными
- Начиная, представляйте конечную цель
- Сначала делайте то, что нужно делать сначала
- Думайте в духе выиграл — выиграл
Будьте проактивными — предложите решение возникшей проблемы. У некоторых менеджеров на двери даже висит соответствующая табличка “без предложений не входить”.
Начиная, представляйте конечную цель — конечная цель тут не решить задачу, а удовлетворить текущие потребности бизнеса.
Сначала делайте то, что нужно делать сначала — вот оно решение возникшей проблемы. Самостоятельно узнаем приоритеты и разобъем задачу на этапы!
Думайте в духе выиграл — выиграл — этапность позволит выпустить готовую функцию даже раньше установленного срока. Менеджер охотнее примет предложение об этапах, если пораньше получит нужную функцию.
Припомним также определение Scrum-методологии — это набор принципов позволяющий в жёстко фиксированные и небольшие по времени итерации предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет.
Действия такие:
- Разбиваем задачу на подзадачи — проактивный подход. Не спрашиваем менеджера, делаем самостоятельно.
- Выясняем приоритеты каждой подзадачи.
- Разбиваем задачу на этапы.
- Совместно с менеджером корректируем сроки.
- Поэтапно решаем большую поставленную задачу.
Подзадачи получились такие:
- реализовать paypal,
- реализовать yandex деньги,
- реализовать QIWI wallet
Менеджер корректирует список подзадач. Приоритеты установили на основе процента клиентов, которые хотели бы пользоваться платежными системами. Получили такие этапы:
- Yandex.Money 60% пользователей
- QIWI Wallet 30% пользователей
- PayPal — 10% пользователей.
Совместно с менеджером установили такие сроки:
- Yandex.Money — 3 дня
- QIWI Wallet — 4 дня
- PayPal — 2 дня.
Результаты:
Получилось, что мы не упеваем решить задачу за неделю, однако намного раньше релизим полезную функцию для клиентов.
Разбиение на этапы я показал на простой задаче. На практике задачи намного труднее, этапов больше, менеджеры не соглашаются с предложенным. Для обоснования используем UML диаграммы.
Диаграммы наглядно показывают, что задача составная, каждый элемент содержит в себе множество деталей и особенностей. Опираясь на такое наглядное описание, вы обосновываете, почему не получается реализовать задачу в установленные сроки.
Сроки выполнения отдельных элементов оцениваются точнее сроков выполнения большой задачи.
Выводы:
- Вместо оправданий и жалоб на неадекватные сроки вы предложили конструктивное решение — разбить задачу на этапы.
- С помощью диаграмм вы доказали сложность задачи и обосновали, что эту задача разбивается на этапы.
- Менеджер доволен — первый релиз (этап 1) состоялся раньше установленных сроков, появилась полезная документация.
- Вы улучшили навыки общения с менеджментом, избежали неадекватных сроков и больших переработок.
- Вы улучшили навыки проектирования и документирования за счет того, что предоставили некое готовое решение, которое улучших опытный коллега.
- Работа стала интереснее — вы узнали дополнительную информацию о проекте (приоритеты пользователей)
Выводы в виде советов:
- Приходите с готовым решением. Вы получите дополнительный бонус — ошибки корректируют.
- Не тратьте много времени на разбиение задачи на подзадачи. Смысл — подготовить черновик для обсуждения.
- Не приступайте к кодированию. Даже если менеджер спроектировал и нарисовал схемы до вас. Набросайте собственную интерпретацию задачи. Это позволит уточнить неясные моменты и сэкономит вам массу времени.
- Пробуйте расставлять приоритеты самостоятельно.
- Проектируйте сами и не рассчитывайте на то, что менеджер или тим лид вами всецело управляют и корректируют шаги. У них нет на это времени.
Ссылки:
- книга Стивена Р. Кови «7 навыков высокоэффективных людей»
- Scrum-методология
- Стив Макконнелл — Совершенный код. Мастер-класс — о пользе проектирования и псевдокодинга.
- Разработка через страдание
P.S.
- Жду ваших ссылок и полезных советов в тему — добавлю в статью
- Если тема интересна — напишу статью, где на сложном примере разберу процесс проектирования и разбиения задачи на этапы.
Автор: HotFire
