Успеть в кратчайшие сроки — разработка этапами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 навыков высокоэффективных людей» ^[1]
• Scrum-методология ^[2]
• Стив Макконнелл — Совершенный код. Мастер-класс ^[3] — о пользе проектирования и псевдокодинга.
• Разработка через страдание ^[4]

P.S.

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

Автор: HotFire

Источник ^[5]