В первую очередь хочу отметить, что все описанное ниже основано на реальном опыте работы и не является моими личными пожеланиями.
Чтобы правильно оценить задачу, проект нужно:
1. Собрать список требований к проекту.
Если есть техническая документация, то требовать её.
Если нет – составить список вопросов и постараться выяснить о проекте как можно больше.
Любое неучтенное желание заказчика – минус в карму, что может повлиять на оценку и даже на оплату.
Примеры реальных списков вопросов:
Пример 1
Пример 2
2. Далее много зависит от объема работы и маcштаба проекта.
Если проект большой и оценить его целиком представляется сложным, то нужно убедить заказчика в необходимости разработки:
Диаграмм процессов (помогают выявить скрытую логику), пример
Wireframe, помогают оценить будущий интерфейс, пример
Подробной технической документации (не даст заказчику возможность требовать с вас неучтенные фичи), пример
3. После этого нужно декомпозировать задачу на более мелкие, более детальный список задач так же помогает выявить скрытую работу.
На практике постоянно сталкиваюсь с тем, когда разработчики дают заниженную первоначальную оценку, причем в 2 или 3 раза!
4. При оценке задачи необходимо учитывать такие скрытые факторы как:
– Время необходимое на ознакомление с проектом, если разработка уже начата до вас. Это может занять значительную часть времени.
– Время на изучение новых плагинов, фреймворков, используемых в проекте.
– Время необходимое на развертывание окружения, первоначальную настройку проекта.
– Время необходимое на тестирование и отладку (может занять до половины времени, потраченного на разработку).
– Время потраченное на переписку и согласование новых деталей проекта (они обычно появляются в ходе общения с заказчиком).
5. При декомпозиции задачи на подзадачи важно выделить базовую логику, на которую будет потрачено основное время, без которой остальная разработка невозможна.
А затем уже переходить к частностям. Зачем это нужно? Заказчик часто пытается урезать проект, чтобы сократить издержки, поэтому важно не дать ему урезать время заложенное на базовую логику проекта.
Пример плохой декомпозиции на подзадачи.
– Авторизация с помощью емейл – 8 часа
– Авторизация с помощью facebook – 6 часа
Пример декомпозиции на подзадачи с учетом базовой логики:
– Создать модель пользователя – 3 часа
– Серверная логика для работы с сессиями – 3часа
– Серверная логика для работы с протоколом OAuth – 3 часа
– Серверная валидация – 3 часа
– Клиентская валидация – 2 часа
– Логика авторизации через facebook – 3 часа
Пример выше не является идеальным, так как он не учитывает, к примеру, логику обработки ошибок при работе с соц сетью и т.д., но он не даст возможность отнять у вас время на работу с базовой логикой проекта.
6. Часто встречаются ситуации, когда заказчик сам пытается диктовать условия разработки, в том числе время необходимое на разработку, не имея при этом достаточной компетенции.
Важно не поддаваться желанию угодить клиенту и отстаивать свои сроки и инструменты, которые вы планируете использовать при разработке.
Помните, заказчик всегда пытается получить лучшее по минимальной цене, не идите на поводу!
7. Так же есть некоторые различия при работе работе по фиксированной цене и часовой ставке. Цену за проект по фиксированной ставке всегда надо назначать дороже, чем она могла бы быть на 20-30%, так как она включает в себя издержки на согласование мелких доработок из-за различий в видении результата с заказчиком.
We are looking forward to meeting you on our website blog.soshace.com
