В сфере IT существуют два вида разработчиков: "люди-часы" и "люди-результаты". Однако наш разговор будет обращён к более важному аспекту. Проблема сроков в ИТ укоренилась с глубокой историей и ещё доселе не обрела универсального решения. В этом тексте мы разведаем коренной источник данной затруднительности и предложим полезные советы по эффективной работе со сроками.
Обозначим сердцевину проблемы
Оценка задач не вызывает эмоций, похожих на радость. В случае, когда задача стандартна, проект хорошо проработан и все возможные преграды учтены - ситуация меняется. Но, когда на повестке дня новый проект, задача, прибывшая от неизвестного человека, неизученный код и...
- Сколько времени потребуется для выполнения этой задачи?
- Когда необходимо закончить?
- Нужно было сделать это вчера.
В подобных контекстах обычно витает оптимистичный прогноз. Но впоследствии либо сроки нарушаются, либо специалист выдыхается. Это прямо связано с несовершенством коммуникации между менеджером и разработчиком. Правильное решение проблемы включает в себя установление адекватного канала обратной связи. Пример для прозрачности:
- Это нужно было сделать вчера.
- Дайте мне два часа, Васечкин, я изучу ситуацию и доложу.
При этом, Васильев должен иметь возможность задать вопрос, почему ему необходима целая неделя на разработку корзины для интернет-магазина, когда на прошлом проекте они справились за три дня.
Если программист допустил ошибку в оценке сроков, он не должен чувствовать себя как на казни. Необходимы специальные "кризисные" мероприятия. Например, запасное время или возможность приостановить некоторые параллельные проекты без нарушения сроков их выполнения.
В ответ на вторую проблематику – применяемый подход для верной оценки временных промежутков:
1. Вопрос выявления наилучшей временной единицы:
Неоспоримо исключите минуты, а к часам относитесь с крайней осторожностью. Если в вашем ведении отдел создания программ, наиболее притягательным выбором будет тот формат, который не сжимает половину рабочего периода. Такое актуально, если задача банальна, знакома, и кодеры уже неоднократно ее реализовывали.
Оценочная система, базирующаяся на рабочих днях, имеет более высокую точность, к тому же обеспечивает необходимый временной промежуток для непредсказуемых ситуаций. Более того, она участвует в учете части стандартных рисков, о которых мы обсудим впоследствии.
2. Адекватная постановка задачи:
Главная функция менеджера – получение от заказчика ясного технического задания. Без него даже при наиболее аккуратно спрогнозированных сроках задача подвержена угрозе провала. Например, задача «Хочу, чтобы в личном кабинете была возможность просмотра и загрузки истории покупок» не является полностью сформулированной. Вместе с запросом должны идти:
- Критерии приема
- Важные детали
- Дизайн
Пример ясной и адекватно сформулированной задачи:
Хочу, чтобы в личном кабинете была возможность просмотра и загрузки истории покупок. Необходима возможность выбора периода и получения документа в формате, совместимом с Excel 2007 и более новыми версиями.
Представляю дизайн формы экспорта. Критерии приема следующие:
- Кнопка экспорта доступна
- При активации кнопки экспорта появляется таблица с возможностью выбора необходимого периода
- После окончания выбора периода, пользователю предлагается возможность загрузить файл на диск
- Отчет подготавливается не более 25 секунд
3. Предвидение испытаний
По мере углубления в сложные инициативы, "постулат злонамеренности" неукоснительно действует. Рассчитывайте на уделение пары часов или даже полдня на исследование сложности задачи и потенциальных преград во время реализации.
Если проект выглядит идеальным, с безупречным программным обеспечением, логической архитектурой и удобством интеграции с внешними услугами, можно смело назначать оптимистичные сроки. Но каждая предвидимая преграда - это дополнительные 20-40% времени.
Не пренебрегайте учётом всех типичных моментов, которые могут вызвать провалы в сроках, и произведите их оценку.
Предлагаем контрольный список.
1. Неожиданные "приятности" от заказчика во время выполнения работ или расплывчатое техническое задание.
2. Клиент задерживает предоставление необходимых данных, и работа останавливается из-за отсутствия дизайна, неподтвержденных этапов, некорректного файла для загрузки и т.д.
3. В процессе вы столкнулись с задачей, которую не заметили при оценке. И то, что казалось «только три строки и готово», превратилось в половину рабочего дня поиска причин, почему почта на сайте не функционирует.
4. Заболевания, семейные проблемы, истощение у профессионалов.
5. Часть команды не укладывается в сроки, и задачи взаимосвязаны.
Пункты 1-3 учитываются при оценке рисков. Четвертый относится к форс-мажорам и требуется инструмент для объяснения ситуации клиенту. Что касается последнего… Здесь есть короткое руководство.
4. Декомпозиция проекта на элементарные задания
Когда перед вами стоит задача "создать систему управления проектами", это гигантский объем работы. Ее следует разбить на более мелкие, автономные блоки.
Если у вас есть актуальная задача и вы распределили ее выполнение между разными специалистами, то каждый из них должен иметь возможность завершить свою часть работы и немедленно проверить результаты.
Таким образом, обязательными становятся не только глобальные цели проекта, но и более мелкие подзадачи. Этот процесс, известный как декомпозиция, позволяет эффективно распределять работу, минимизируя риск задержек и упрощая координацию действий команды.
Тщательное планирование и организация являются ключом к успешной реализации сложных проектов. Однако даже самые тщательно спланированные проекты могут столкнуться с непредвиденными трудностями. Научившись предвидеть эти трудности и адекватно реагировать на них, вы сможете обеспечить своему проекту плавный ход и успешное завершение.
А как ставишь дедлайны ты? Ставь лайк и делись в комментариях.