Приемка курса. Любимые грабли
Сколько уже говорено и на публику и внутри компании о том, что тексты и прочие элементы не подлежат изменению в рамках проекта, что мы утверждаем всё это добро на этапе принятия эскизов и сценария.
И всё равно, на голубом глазу, при обсуждении внедрения электронного курса несколько классических реплик вроде “Ой, а давайте вставим ему бэджик?” Конечно вставим, по всему курсу пройдёмся и вставим. Раз плюнуть.
Другой классический прием – подписать ТЗ, а на приемке вычитывать тексты и на лету рождать новые – гениальные разумеется. В общем и целом с одной стороны приятна такой тщательный подход, но на каком этапе :).
Позволю себе привести очень простой пример. Вы заказываете себе окно. Вам его меряют, вас спрашивают в какую сторону и что должно открываться, какая будет фурнитура, какого цвета и сколько там будет камер. Потом вы подписываете заказ-наряд. После чего вам устанавливают то, что вы заказали. Вы сверяетесь с собственными ощущениями, с заказом-нарядом и подписываете акт. Точка.
А теперь представьте такой например вопрос при приемке работ: “А давайте сделаем не две, а три камеры?” или “Что-то мне кажется, что таки влево открываться – оно удобней.” Как думаете, что ответят бравые ребята, которые смонтировали вам окно? :) Поверьте в разработке программных продуктов тоже самое.
Уважаемые клиенты, будьте так любезны, пожалуйста, относитесь бережливо к своему времени и к своим бюджетам, читайте ТЗ и боритесь за ТЗ. В нём вся соль. Дальше идёт только лишь трансляция того, что написано в ТЗ.
Комментарии
Разумеется, это не означает, что ТЗ можно оформлять невнимательно и не особо задумываясь. И, конечно, хорошо, когда проблемы выявляются не при приемке, а раньше. Но в моем опыте бывало всякое. Я после окончания проектов (в основном внутренних, но и с внешними тоже случалось) во время анализа, как протекал проект, не раз приходил к тому, что заранее предусмотреть некоторые вещи было бы очень сложно.
Гораздо проще заранее предусмотреть, что в процессе обязательно возникнут какие-либо сложности и изменения, и попытаться предположить, где именно с наибольшей вероятностью они могут возникнуть. И постараться заранее подстелить соломки там, где есть риск упасть.
В общем, тут, на мой взгляд, вопрос скорее в эффективном управлении проектом (и эффективными коммуникациями внутри него). PM-эксперт недавно проводили интересный вебинар на эту тему. Говорили о таких формальных документах в проекте, как план коммуникаций (где прописано, например, кто когда кому какую информацию предоставляет, что когда и с кем согласовывает и многое другое), таблице возможных рисков (куда в любой момент любой участник может внести свои опасения, и тогда они обязательно должны быть рассмотрены в определенный нормативный срок) и других интересных вещах.
И еще одна очень важная вещь - проактивность. Поменьше обвинять других участников проекта в том, как они плохо работают. И побольше думать, что можно самому сделать для того, чтобы избежать проблем. Даже если приходится при этом делать что-то необычное и нетипичное для себя. То, что обычно хочется отдать под чью-то еще ответственность. Это очень помогает.
Более того, считаю, что даже если клиент после утвреждения документации таки считает, что в куре что-то надо улучшить это надо делать. Гораздо хуже, когда клиент принимает курс без пристрастия.
Мы как правило идём на уступки в части оперативных доработок.
Однако, есть всему есть свой предел и разумные рамки.
В первопричине того, что послужило поводом для такого рода поста был таки мессежд для обоюдного движения настречу :).