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

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

Привожу советы, которыми руководствуюсь сам и которые меня ни раз выручали. Каждое утверждение требует обсуждения, осмысления и критики.
Тон статьи кажется категоричным. Сразу же извиняюсь за это. Для краткости опустил фразы “я думаю”, “я полагаю” и проч.

Поделюсь опытом на основе примера. Придумаем же следующую задачу. Цифры и сроки условные.

Разрабатываем сайт e-commerce, который продает детские игрушки. Оплата только наличными. Реализовываем оплату безналичными с помощью:

• PayPal;
• Yandex.Money;
• QIWI Wallet;

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

• Задачи срочные, успейте сделать
• Ок, я приостановлю 2 задачи. Остальные 3 задачи выполняйте параллельно
• Ок, я продлю срок этой задачи на 1,5 недели

Эти варианты вас не устраивают. Времени не хватит. Вы оказались в тупике и задумались о таких решениях:

• придти на работу пораньше.
• задержаться на работе подольше.
• Вы и так постоянно задерживаетесь, задерживаться придется в 2 раза дольше.

Как же быть?
Тут поможет книга Стивена Р. Кови «7 навыков высокоэффективных людей»

1. Будьте проактивными
2. Начиная, представляйте конечную цель
3. Сначала делайте то, что нужно делать сначала
4. Думайте в духе выиграл — выиграл

Будьте проактивными — предложите решение возникшей проблемы. У некоторых менеджеров на двери даже висит соответствующая табличка “без предложений не входить”.

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

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

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

Действия такие:

1. Разбиваем задачу на подзадачи — проактивный подход. Не спрашиваем менеджера, делаем самостоятельно.
2. Выясняем приоритеты каждой подзадачи.
3. Разбиваем задачу на этапы.
4. Совместно с менеджером корректируем сроки.
5. Поэтапно решаем большую поставленную задачу.

Подзадачи получились такие:

1. реализовать paypal,
2. реализовать yandex деньги,
3. реализовать QIWI wallet

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

1. Yandex.Money 60% пользователей
2. QIWI Wallet 30% пользователей
3. PayPal — 10% пользователей.

Совместно с менеджером установили такие сроки:

1. Yandex.Money — 3 дня
2. QIWI Wallet — 4 дня
3. PayPal — 2 дня.

Результаты:

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

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

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

Выводы:

1. Вместо оправданий и жалоб на неадекватные сроки вы предложили конструктивное решение — разбить задачу на этапы.
2. С помощью диаграмм вы доказали сложность задачи и обосновали, что эту задача разбивается на этапы.
3. Менеджер доволен — первый релиз (этап 1) состоялся раньше установленных сроков, появилась полезная документация.
4. Вы улучшили навыки общения с менеджментом, избежали неадекватных сроков и больших переработок.
5. Вы улучшили навыки проектирования и документирования за счет того, что предоставили некое готовое решение, которое улучших опытный коллега.
6. Работа стала интереснее — вы узнали дополнительную информацию о проекте (приоритеты пользователей)

Выводы в виде советов:

1. Приходите с готовым решением. Вы получите дополнительный бонус — ошибки корректируют.
2. Не тратьте много времени на разбиение задачи на подзадачи. Смысл — подготовить черновик для обсуждения.
3. Не приступайте к кодированию. Даже если менеджер спроектировал и нарисовал схемы до вас. Набросайте собственную интерпретацию задачи. Это позволит уточнить неясные моменты и сэкономит вам массу времени.
4. Пробуйте расставлять приоритеты самостоятельно.
5. Проектируйте сами и не рассчитывайте на то, что менеджер или тим лид вами всецело управляют и корректируют шаги. У них нет на это времени.

Ссылки:

• книга Стивена Р. Кови «7 навыков высокоэффективных людей»
• Scrum-методология
• Стив Макконнелл — Совершенный код. Мастер-класс — о пользе проектирования и псевдокодинга.
• Разработка через страдание
• Проектирование, декомпозиция, использование UML (Крэг Ларман). (спасибо, AlexanderG)

P.S.

1. Жду ваших ссылок и полезных советов в тему — добавлю в статью
2. Если тема интересна — напишу статью, где на сложном примере разберу процесс проектирования и разбиения задачи на этапы.