В предыдущих статьях ( первый , второй ) мы быстро и с юмором разобрались с примерами противодействия, которое нам оказывают сотрудники заказчика на разных этапах проекта.
Сегодня предметом рассмотрения станет сдача работ, и к этому этапу мы подойдем во всеоружии, чтобы ни один тролль не прорвался.
Букв получилось много, но надеюсь оно того стоит. Сдача результатов работы – один из самых драматичных этапов проекта.
Человеко-месяцы, потраченные на разработку, отладку, тестирование и внедрение вашего решения, не должны быть потрачены впустую.
Если вам доверили сдачу работы, то ваша роль в коллективе очень значительна, и доверие руководства велико, даже если ваше начальство никогда не говорило вам об этом.
Провал с бумагой иногда означает конец великой карьеры.
Так что лучше этого не делать.
Процесс приемочных испытаний должен быть строго формализован.
Всем понятно, что по итогам этого процесса должен появиться протокол и акт, на основании которых выдается приказ о передаче системы в опытную или промышленную эксплуатацию.
Акт также является формальным основанием для выставления счета на оплату следующего этапа проекта.
В этой статье без лишних шуток (какие там шутки!) и максимально последовательно (ну, для блога, конечно) я опишу процесс подачи проектных работ. Конечно, опытным коллегам многие вещи покажутся очевидными.
Пусть будет. А вот менее опытные коллеги или желающие примерить на себя ответственную роль тестируемого найдут эту публикацию полезной и информативной.
Направления троллинга во время тестирования
Вы даже не представляете, сколько людей заинтересовано в вашей неудаче! Кто-то хочет доказать свою правоту насчет ваших умственных способностей, кто-то хочет затянуть сроки, кто-то мечтает о штрафах, кому-то нужны новые шины на БМВ.В таких случаях в комиссию поместят тролля-убийцу (см.
первый пост).
На данном этапе есть три направления троллинга, с которыми вам предстоит столкнуться:
- Официальное принятие.
Тролль указывает на техническое задание, где написано что-то вроде: «система должна иметь клиент-серверную архитектуру».
Вам нужно показать, как закрывается элемент. А в пояснительной записке к техническому заданию вы забыли включить строку «Система имеет клиент-серверную архитектуру» или с перепугу не смогли ее найти.
Не торопитесь, просмотрите все разделы технических характеристик и найдите нужные вам строчки.
- Ошибки в тестах.
При формулировании тестов избегайте возможности преднамеренного неправильного толкования.
Например, вы пишете: «Из списка пользователей Оператор выбирает любого пользователя».
Тролль выберет из списка системного пользователя или администратора, под которым тесты работать не будут. Или пишете «Свойства всех объектов отобразились».
Тролль будет тыкать на объект, свойства которого не отображаются.
И вы имели в виду «все необходимые объекты», но поезд ушел, и вы получаете страшную надпись «Свойства всех объектов не отображаются».
- «Очень важные замечания».
Когда затихли пушки основного боя, начинается анализ комментариев на критические и некритические.
Критические из них станут костью в горле; они мешают подписанию акта.
Поэтому тролль постарается каждый комментарий сделать критическим.
Включается весь существующий пафос, привлекаются авторитетные товарищи, кивают головами и прочий цирк с лошадьми.
Программа испытаний и методика
Документ PMI, или программа испытаний и методология, на мой взгляд, важнее даже технических спецификаций.Половина, если не две трети успеха испытаний зависит от качества этого документа.
Требования к содержанию документа описаны в разделе 2.14. ГОСТ РД 50-34.698-90. , также известный как «Стандарт технического писателя».
Что должен содержать этот документ:
- Полная формальная часть по ГОСТу (объект и цель испытаний, объем и условия испытаний и т.п.
).
В результате, прочитав эти разделы, любой член комиссии, даже если он еще не участвовал в проекте, должен понять, что именно передается и какова во всем этом его личная роль.
- Проверка комплектности всего и вся - документации, дисков, количества переданных копий и т.д. Соответственно, все это должно физически присутствовать для тестирования.
Целью является выполнение формальных требований технических спецификаций и контракта на поставку.
- Описание того, как именно проводятся испытания.
Будете ли вы скармливать системе реальные данные с физических датчиков или подсовываете тестовые файлы или эмулятор? Будет ли система управлять реальным объектом или достаточно посмотреть логи, где написано, что она сделала то-то и то-то? Должен ли пользователь торжественно сидеть в диспетчерской или можно ограничиться ноутбуком в офисе?
- Системные тесты высокого уровня.
Детали могут отличаться в зависимости от заказчика.
Есть как общие тесты, так и тесты с пошаговыми инструкциями.
Цель испытаний проста: при прохождении последнего испытания необходимо выполнить все функциональные требования технического задания, а также отметить тот факт, что эксплуатационные документы содержат требуемую информацию (то есть они пригодны для работы).
.
- Сценарий тестирования.
Тесты следует располагать в том порядке, в котором вы хотите минимизировать время тестирования и ненужные вопросы.
Например, если вы проверяете прием, перевод и увольнение сотрудника в кадровой программе, то пусть сценарий будет именно такой — вы кого-то нанимаете, потом переводите, потом увольняете, чтобы не пришлось нанимать работника.
каждый раз новый сотрудник и тратите на это время.
Или другой пример.
В одном из тестов вам следует проверить резервное копирование и восстановление системы.
Если тестирование проводится несколько дней подряд, разумнее запланировать резервное тестирование на конец первого дня.
Тогда не нужно было бы ждать окончания длительной процедуры.
А восстановление можно запланировать на предпоследний день.
Перед восстановлением вы можете выполнить строгие тесты, такие как эмуляция сбоя, потери журналов и важных файлов (если вам, конечно, нужно это протестировать).
Сейчас это кажется очевидным, но прочитайте реальные документы, чтобы увидеть, что это не очевидно для всех!
Отчет об испытаниях
На основании тестов PMI вы должны подготовить отчет об испытаниях.Протокол будет документом, подтверждающим, что ваша система изготовлена в соответствии с техническими условиями, о чем в акте делается соответствующая запись.
Не поручайте составление протокола кому-либо другому, если не хотите выглядеть бледным перед комиссией.
Обычно протокол представляет собой «копипаст» ПМИ, поэтому его подготовка не займет у вас много времени.
Протокол испытаний состоит из общей части, таблицы испытаний и списка комментариев.
Таблица, в которую заносятся результаты испытаний, может состоять из следующих граф:
- Через номер (в удобном для вас формате).
Например, Номер_теста.
Номер_шага.
- Действия оператора.
Что делает оператор, чтобы получить результат? Убедитесь, что язык предотвращает злонамеренное неправильное толкование.
- Ожидаемый результат. Говоря простыми словами, описываемый результат действий оператора, который можно проверить (потрогать, увидеть, понюхать).
Например: «Загорелся зеленый свет на верхней панели», «В списке пользователей появился новый пользователь», «На экране появилось предупреждение системы о неправильно введенном пароле», «В системе появилась запись Y».
журнал X».
Убедитесь, что формулировка максимально конкретна и предотвращает злонамеренное неправильное толкование.
Помните также о словах, которые являются пищей для троллей: «любой», «каждый», «все», «ни один» и т. д.
- Пункт в документации (например, Руководстве пользователя), в котором подробно описывается действие, которое необходимо выполнить, или закрывается нефункциональное требование технической спецификации.
Наличие этого предмета позволит вам убить двух зайцев одним выстрелом.
Сначала вы документально оформляете все, что необходимо отразить в проектной документации.
Во-вторых, вам не придется подробно описывать действия оператора, поскольку (внимание!) к испытаниям допускаются только сотрудники, соответствующие требованиям технического проекта, в которых вы написали, что они должны пройти определенные курсы и знать эксплуатационную документацию.
- Позиция или позиции технической спецификации, которые закрываются на данном этапе.
Сумма в графе должна отражать все (а именно все, а не только функциональные!) требования технического задания.
Именно поэтому протокол будет содержать «тупые тесты» для проверки полноты документации, написания программы на Java и реляционности базы данных СУБД Oracle (указываем пальцем на соответствующий раздел документации).
- Решение комиссии.
Необходимо настоять на следующих решениях: «Пройдено», «Пройдено с комментариями», «Не пройдено», «Не проверено».
Других записей здесь быть не должно.
Запись «Не тестировалось» делается для испытаний, которые комиссия не хотела проводить или было физически невозможно провести на момент тестирования.
Например, решили не выдергивать узел кластера из сокета.
Лучше, чтобы таких записей в протоколе не было, чтобы не было лишней возможности для троллинга.
- Комментарии.
Если тест пройден с комментариями, здесь должен появиться номер комментария.
Все замечания фиксируются в приложении к протоколу в свободной форме.
Вы можете указать номер теста, во время которого возникли комментарии.
На большее у вас просто не хватит времени.
Если решение комиссии «Принято», постарайтесь ничего не писать в графе «Комментарии».
генеральная репетиция
Без нее невозможно.Только так вы сможете уловить все острые углы в тестах, выявить тесты, которые крадут время и тесты, результаты которых сомнительны.
Помните, что визуальная составляющая должна быть безупречной.
Постарайтесь ввести в систему данные, которые выглядят естественно и похожи на то, с чем имеет дело клиент. Убедитесь, что имена пользователей и другие поля не содержат ненормативной лексики (любимая шутка реализаторов и программистов).
Эти «шутки» иногда действуют на комиссию как красная тряпка на быка.
Не бойтесь переписывать PMI с нуля.
Однажды мы потратили время и переставили тесты вместо того, чтобы переписать их.
В результате мы просто успокоились, не меняя общей плачевной картины.
Вот почему их обграбили.
Если вы сдаете тесты вместе, сдавайте тесты вместе.
Пригласите коллег, пусть придираются, выдавая себя за комиссию.
Время, потраченное на эти игры, в конечном итоге позволит всем вам получить деньги от довольного клиента.
Ээффектный дуэт
Оптимальная команда для поставки — пара внедрителя (или программиста) и бизнес-аналитика (консультанта).Реализатор (программист):
- работает с системой, демонстрируя владение интерфейсом
- отвечает на технические вопросы
- рассказывает о системе с заказчиком, ведет беседу
- отвечает на общие вопросы
- занимает минуты
- пинает исполнителя (программиста) под стол
Если программист вдруг наступит на баг, консультант может дать ему по голове и быстро поболтать с заказчиком, возмущаясь чьими-то кривыми руками.
Эффект будет как в цирке.
Заказчик посмеется про себя и сразу подумает, что он не клоун и руки у него будут прямее.
Точно так же, если консультант говорит какую-то глупость, а заказчик в ответ морщится, программист может с лицом оскорбленной невинности продемонстрировать еще одну особенность системы, и тогда заказчик к нему потеплеет, потому что он поймет кто настоящий профи, а кто клоун в галстуке.
В особо напряженные моменты можно устроить дружескую перепалку, разрядив тем самым ситуацию и отвлекая внимание зрителей от не совсем корректной работы системы.
Не зря западные «ИТ-евангелисты» любят работать в парах.
Процесс начался!
Приступая к тестированию, не смейте сразу лезть в систему! Постарайтесь сначала пройти всю формальную часть.Проверьте коды документации и носителей информации, откройте технические характеристики и положите на стол Руководство пользователя.
Просмотрите нефункциональные требования.
ОС Windows – галочка.
Поддерживаемые версии браузеров – раз, два, три, галочка.
Язык разработки, архитектура, база данных, мало ли что написано в ТЗ! Все должно быть отражено в документации.
По крайней мере, есть только одно предложение, оно должно быть там! Не пренебрегайте этой бюрократией, этого и ждут тролли.
Вы хотите получить в протоколе следующее: «Исполнитель не продемонстрировал, что язык Java является кроссплатформенным языком высокого уровня.
Требования ТК 1.2.3 и 3.2.1 не соблюдены»? Но это не придуманное безумие, это сама жизнь.
Закончив с формальной стороной дела, тоже не торопитесь в систему! Следующая группа тестов состоит из включения монитора и демонстрации рабочего стола, значков и запуска программы (если запуск необходимо протестировать).
Войти с неправильным паролем, галочка, войти с правильным паролем - снова галочка, галочка, галочка.
Меню невероятное! Основная форма, список чего-либо.
Галочка.
Когда дело дойдет до нажатия кнопок в системе, комиссия уже будет изрядно уставшей и голодной.
А в первый день вы сможете пропустить, например, базовые справочники и базовые функции.
А бэкап, администрирование и прочую ерунду оставьте на другой день.
Примечания
Они будут, можете быть уверены.Не существует системы, к которой не было бы комментариев.
Ваша задача — заставить заказчика разделить все комментарии на критические и некритические.
Первое необходимо исправить для успешной передачи в опытную эксплуатацию.
Последнее можно исправить в ходе опытной эксплуатации.
Соответственно, лучше, чтобы первых не было вообще или чтобы были только те, которые не сложно исправить.
Когда клиент делает замечание, вы записываете его формулировку в протокол.
Обязательно говорите написанные слова и убедитесь, что вы понимаете друг друга.
Было бы лучше, если бы во время тестов работал диктофон.
Постарайтесь сделать так, чтобы формулировка замечания была конструктивной, то есть было понятно, что нужно сделать, чтобы замечание было удалено.
К словам «все», «ничего», «каждый», «любой», а также неизмеримым качественным оценкам «плохо», «медленно», «слишком быстро» и т.п.
замечаний быть не должно! Если «система работает медленно», то должно быть написано «запрошенная форма должна отобразиться в течение 5 секунд».
Если «обозначения на схеме плохо различимы», то следует написать «увеличить обозначение на схеме до 18 пунктов».
И так далее.
Уточнение сведет к минимуму возможность необоснованного перетягивания того или иного комментария в ранг критического.
Заказчик может возразить, что обработка запроса за 6 секунд для него неприемлема, но за 5 секунд — в самый раз.
Пусть это появится в протоколе! Но что-то мне подсказывает, что оно не появится.
Либо замечание будет считаться некритичным.
Все замечания, признанные критическими, фиксируются в акте: «Комиссия решила, что система соответствует техническим условиям и рекомендует принять ее в опытную эксплуатацию при условии отработки следующих замечаний:.
».
список некритических замечаний лучше не включать непосредственно в акт. Их обычно много и они могут напугать ответственного сотрудника, который подписывает. Если заказчик переживает, что вы не отреагируете на некритические замечания, успокойте его с помощью документа «Методология опытной эксплуатации», подготовить который настоятельно рекомендуется.
Там вы должны в простой и доступной форме описать, как будет проходить опытная эксплуатация, как будут отрабатываться найденные ошибки и как будет заполняться журнал опытной эксплуатации, что является гарантом безболезненного завершения О?, ввод системы в промышленную эксплуатацию и салют шампанским по случаю окончания проекта.
Что делать, если все потеряно
Когда понимаешь, что тесты идут неудовлетворительно, система вопиюще глючит, а запас ругательств у заказчика уже исчерпан, не нужно сдаваться! Караван должен продолжать двигаться вперед, будет новый выпуск, новые испытания.И даже если проект провалится, для вас в этом нет ничего страшного.
В условиях острой нехватки толковых исполнителей вы быстро найдете работу, тем более, что на вашем месте я бы не работал в компании, допускающей такие ситуации.
Чтобы не тратить время на бесплотные пререкания, я бы рекомендовал использовать тактику «бей своих, чтобы другие боялись».
Начните с того, что заказчик отругает «этих кривых программистов», «жадное руководство», а когда накал страстей уменьшится, предложите заказчику собрать как можно больше багов из «этого глюка», чтобы показать этим нехорошим людям, какие они плохие.
являются.
Тогда активные сотрудники заказчика во главе с троллем-убийцей начнут собирать баги и радостно заполнять протокол сотнями комментариев.
По сути, за свой счет они проведут вам высокоуровневое функциональное тестирование, чего, судя по результатам тестирования, ваши разработчики так и не смогли сделать.
К счастью, описанная безобразная ситуация вообще не должна существовать.
Но проектному бизнесу иногда свойственны странные колебания, когда первый прототип пытаются сдать как полноценную систему, начальство лжет подчиненным и себе, все вокруг делают хорошую мину при плохой игре и уверяют друг друга.
обязательного и неизбежного успеха.
Вторым советом в такой ситуации будет, как я уже сказал, немедленно уходить с той конторы, которая допускает такие «косяки».
Потому что по всем меркам настоящий профессионал не должен таким образом портить свою репутацию.
Заключение
Итак, коллеги, на этом спешу завершить трилогию о корпоративных троллях, которых не нужно бояться, а нужно уважать и даже в какой-то степени любить, поскольку они не дают падать ленивым обезьянам ИТ-бизнеса.от деревьев от обжорства, держат нас в напряжении и даже вызывают некоторый интерес к безумно скучной, но крайне необходимой дизайнерской работе.
UPD от 23.06.2011 .
Пользователь игендо добавляет в комментариях, что было бы неплохо утвердить формы официальной проектной документации уже на этапе заключения договора.
Я цитирую: Добавлю, что очень помогает в работе, когда в договоре фиксируются формы актов, протоколов и других официальных документов.
Чтобы не было необходимости заранее согласовывать, пересогласовывать и переделывать/переподписывать их в середине проекта.
От себя могу еще добавить, что в очень сложных и масштабных проектах принято составлять устав проекта, своего рода документ, о глубоком смысле которого можно говорить часами.
Там, помимо прочего, можно обсудить формы проектной документации, процедуры контроля хода реализации проекта и бизнес-задачи высокого уровня.
Но это, опять же, тема для другого поста.
Пользователь Живого Журнала ryzhij_papa добавляет, что существует практика ранжирования комментариев по степени их влияния на бизнес; метод ранжирования также вводится в PMI. Я цитирую: Необходимо формально описать, какие комментарии являются критическими, высоко-, средне- и низкоприоритетными.
Описание выполнено в деловой терминологии.
Если утрировать, то так: критический приоритет при потере 1000 долларов, высокий, если это 100 долларов, средний, когда у сотрудников проблемы, а потерь у нас нет, низкий - возможны случаи легкого помешательства на 5-6-м году жизни при такой баг.
Теги: #троллинг #PMI #тестирование #закрытие проекта #Управление проектом
-
Компьютерные Игры: От Старого К Новому
19 Oct, 24 -
Как Защитить Свою Облачную Инфраструктуру
19 Oct, 24 -
Bash.org.ru Запустил Комиксы
19 Oct, 24
