Поиск по этому блогу

среда, 22 сентября 2010 г.

Приемка курса. Любимые грабли

Сколько уже говорено и на публику и внутри компании о том, что тексты и прочие элементы не подлежат изменению в рамках проекта, что мы утверждаем всё это добро на этапе принятия эскизов и сценария.

И всё равно, на голубом глазу, при обсуждении внедрения электронного курса несколько классических реплик вроде “Ой, а давайте вставим ему бэджик?” Конечно вставим, по всему курсу пройдёмся и вставим. Раз плюнуть.

Другой классический прием – подписать ТЗ, а на приемке вычитывать тексты и на лету рождать новые – гениальные разумеется. В общем и целом с одной стороны приятна такой тщательный подход, но на каком этапе :).

Позволю себе привести очень простой пример. Вы заказываете себе окно. Вам его меряют, вас спрашивают в какую сторону и что должно открываться, какая будет фурнитура, какого цвета и сколько там будет камер. Потом вы подписываете заказ-наряд. После чего вам устанавливают то, что вы заказали. Вы сверяетесь с собственными ощущениями, с заказом-нарядом и подписываете акт. Точка.
А теперь представьте такой например вопрос при приемке работ: “А давайте сделаем не две, а три камеры?” или “Что-то мне кажется, что таки влево открываться – оно удобней.” Как думаете, что ответят бравые ребята, которые смонтировали вам окно? :) Поверьте в разработке программных продуктов тоже самое.

Уважаемые клиенты, будьте так любезны, пожалуйста, относитесь бережливо к своему времени и к своим бюджетам, читайте ТЗ и боритесь за ТЗ. В нём вся соль. Дальше идёт только лишь трансляция того, что написано в ТЗ.

2 комментария:

Михаил Протасов комментирует...

Я считаю, что если в процессе работы оказалось, что изначально неправильно что-то было спланировано, то лучше переделать, чем оставить неправильно. Кто не согласен - можете закидать меня камнями.

Разумеется, это не означает, что ТЗ можно оформлять невнимательно и не особо задумываясь. И, конечно, хорошо, когда проблемы выявляются не при приемке, а раньше. Но в моем опыте бывало всякое. Я после окончания проектов (в основном внутренних, но и с внешними тоже случалось) во время анализа, как протекал проект, не раз приходил к тому, что заранее предусмотреть некоторые вещи было бы очень сложно.

Гораздо проще заранее предусмотреть, что в процессе обязательно возникнут какие-либо сложности и изменения, и попытаться предположить, где именно с наибольшей вероятностью они могут возникнуть. И постараться заранее подстелить соломки там, где есть риск упасть.

В общем, тут, на мой взгляд, вопрос скорее в эффективном управлении проектом (и эффективными коммуникациями внутри него). PM-эксперт недавно проводили интересный вебинар на эту тему. Говорили о таких формальных документах в проекте, как план коммуникаций (где прописано, например, кто когда кому какую информацию предоставляет, что когда и с кем согласовывает и многое другое), таблице возможных рисков (куда в любой момент любой участник может внести свои опасения, и тогда они обязательно должны быть рассмотрены в определенный нормативный срок) и других интересных вещах.

И еще одна очень важная вещь - проактивность. Поменьше обвинять других участников проекта в том, как они плохо работают. И побольше думать, что можно самому сделать для того, чтобы избежать проблем. Даже если приходится при этом делать что-то необычное и нетипичное для себя. То, что обычно хочется отдать под чью-то еще ответственность. Это очень помогает.

Valery L Leontyev комментирует...

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

Мы как правило идём на уступки в части оперативных доработок.

Однако, есть всему есть свой предел и разумные рамки.

В первопричине того, что послужило поводом для такого рода поста был таки мессежд для обоюдного движения настречу :).