Разработчики в первую очередь должны разрабатывать, а не писать документы. Лучше всего возложить оформление документации по использованию системы на тестировщика со своей стороны. Таким образом, вы сможете лучше контролировать процесс, а разработчики при этом будут минимум времени тратить на документацию и ее оформление.
Мелкие и крупные правки. В проекте всегда бывают правки. Написание вами подробного ТЗ не значит, что все будет именно так, как написано в ТЗ. По мере развития проекта вы получаете дополнительную информацию, у вас появляются новые идеи. Возникает желание что-то улучшить. Как быть в этом случае? Если в договоре стоит фиксированная сумма, то вносить большие доработки в приложение без соответствия ТЗ будет некорректным.
При малых правках в большинстве случаев исполнитель идет навстречу заказчику и вносит их в систему.
Если грядут большие перемены, то следует составить новое ТЗ как дополнительное соглашение к договору и изменить план разработки.
Если вы работаете по нефиксированной сумме оплаты, то вы можете сразу менять свои требования к системе. Исполнитель вносит на очередной итерации нововведения по системе.
Старайтесь как можно меньше делать крупных необдуманных изменений в системе. Напишите небольшую концепцию на это изменение и отложите на некоторое время. Если это изменение действительно важно, то вы обязательно вернетесь к нему в будущем.
Всем хотелось бы, чтобы проекты выполнялись четко, быстро, качественно и полном объеме. Но в любом проекте бывают различные проблемы.
Как владельцу проекта вам следует помнить о параметрах проекта: стоимость, сроки, качество, объем работ.
При возникновении проблемы по одному из параметров, вы можете изменять другие и тем самым влиять на проект, чтобы довести его до конечного состояния,
Например, вы не можете закрыть проект в ранее планируемые сроки. В таком случае можно где-то пожертвовать качеством, нанять дополнительно программистов, часть функций убрать.
Не зная о параметрах проекта, очень просто впасть в состояние «Хочу сделать CRM очень качественную, за 50 тыс руб, желательно за 1-2 недели и при этом одна должна содержать все функции 1С». Самое печальное – это не шутка, такие проекты (чаще социальные сети и доски объявлений) встречаются на биржах .
Также важно учитывать человеческий фактор. Нередко проблема именно в личном конфликте участников проекта. Важно знать цели участников проекта. Заказчик должен понимать, что требуется для работы исполнителю. Исполнитель должен понимать, зачем вам нужен проект. Дайте исполнителю всю необходимую информацию и расскажите, для чего вам нужен проект и как вы будете использовать его результаты.
Общение – важная часть взаимодействия. Не скатывайтесь полностью на переписку. Да, в некотором смысле она удобнее, но отсутствие живого контакта влияет на понимание между сторонами. Бывает, что заказчик «садится на уши» исполнителю и перегружает его несущественной информацией. Это заставляет исполнителя избегать заказчика и ограничивать с ним общение.
В нашей практике были разные проекты. Кто-то из заказчиков предпочитал связываться с нами только по электронной почте. А с некоторыми мы на протяжении всего проекта много общались и занимались подготовкой большого количества различных документов. С точки зрения рисков проекта, второй вариант предпочтительнее, но все же надо стремиться к золотой середине.
Также стоит упомянуть о личных встречах. Для людей, привыкших вести бизнес по старой схеме, это является необходимым шагом в ведении проекта.