Схема повышения качества работы с клиентами. Часть 3. Сдача работ.

>>Часть 1. До разработки. Здесь вы сможете посмотреть всю схему целиком.

>>Часть 2. Разработка

И вот наступает самый ответственный момент – сдача работ.

Для начала, я опишу саму схему сдачи работ, которой мы придерживаемся.

Планерка

Окончание фазы разработки и начало фазы тестирования производится на планерке, где обязательно присутствуют все ответственные лица заказчика за конкретные функциональные блоки. На этой планерке озвучивается, что ракета построена и теперь, прежде чем лететь, надо бы попробовать, как работают основные системы. На планерке координируются взаимодействия заказчика и исполнителя, где первые обещают, что как можно быстрее все примут, а вторые обещают, что приложат все усилия для того, чтобы приемка прошла легко и гладко. Второе соблюсти крайне важно. Поддержка первого, как правило, так же требует усилий со стороны исполнителя.

Мы проводим тестирование в четыре этапа.

Первый этап – элементарные блоки

Те самые блоки, которые озвучивались в первой статье. На которые дробилась смета. По сути это огромный чек-лист, который необходимо пройти заказчику и исполнителю вместе, для того, чтобы убедиться, что все работает, как задумывалось. Чек-лист с элементарными блоками содержит поле для подписи ответственного лица и место для примечаний, где указываются все выявленные недочеты. Если разработка проводилась, как описано в предыдущей статье, то на этом этапе выявляются минимальные отклонения, которые имеют поверхностный характер и не являются критичными. Но, мы все равно фиксируем такие замечания с припиской «не является препятствием для запуска в промышленную эксплуатацию».

Если на этом этапе выявляются критические замечания, то они устраняются незамедлительно до перехода на следующий этап.

Второй этап – бизнес-процессы.

Тестируем линейные бизнес-процессы. Отличие от предыдущего этапа в том, что если на предыдущем этапе мы тестировали сами логические элементы, из которых состоят все бизнес-процессы, то здесь мы тестируем стыки между этими блоками. Сами стыки и требования к ним формализуются в описании бизнес-процессов. Об одном из подходов к формализации этого я еще напишу.

Точно так же, как и в предыдущем пункте, мы проходим по бизнес-процессам, фиксируем отклонения, если критичные, тут же устраняем, если не критичные, фиксируем с припиской «не является препятствием для запуска в промышленную эксплуатацию».

На этом этапе возникает большая часть всех выявленных недочетов. Практически всегда это связано с изменившимися за время разработки процессами или их блоками, о чем нас «забыли» предупредить.

Третий этап – опытная эксплуатация.

Если предыдущие этапы тестирования проводятся только с ответственными лицами заказчика, то здесь уже участвуют конечные пользователи. Здесь важно не дать пользователям выполнять работу самостоятельно. Каждый раздел тестирования проводится под контролем консультанта. Он фактически стоит над душой пользователя вживую или смотрит на тот же экран через удаленный доступ. В процессе перехода от одного этапа бизнес-процесса к другому этапу, консультант переключается между пользователями. Это важно, т.к. пользователи имеют свойство пробовать систему «на прочность» и, как правило, отклоняются от сценария тестирования. Наша задача сдать в работу, то что, не выходит за рамки тестирования! Попытки использовать систему вне регламента, должны приравниваться мочеиспусканию в бензобак мерседеса собственника предприятия-заказчика. А что? Проверим дойч-авто-пром на прочность?

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

Четвертый этап – опытно-промышленная эксплуатация

На этом этапе пользователи работают в двух системах одновременно и по итогам какого-то периода сравнивают результаты. Бывало и так, что результаты расходились. Печально, но застраховаться от этого не получается. В этом случае мы берем таймаут и выясняем в чем причина. Причины бывают различными, от наших косяков, до некорректных данных от пользователей.

Особенностью данного этапа является то, что иногда от старой системы уходят в силу ее дефективности, такое бывает. Т.е. работали, работали, терпели, терпели. И вот решили начать жизнь заново, затеяли внедрение. В этом случае, на этом этапе работают в двух системах не для сравнения результатов, а для того чтобы убедиться, что ракета взлетит. И на случай аварии, сохраняют старую проверенную базу в рабочем состоянии. Это более простой случай. Встречали такое на больших объектах при смене торговой системы и системы учета заработной платы.

После окончания этого этапа подписываем протокол об окончании этапа, фиксируем все замечания, устраняем критические. Вторым протоколом фиксируем готовность базы и назначаем дату запуска системы в промышленную эксплуатацию.

Промышленная эксплуатация

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

——

На словах это выглядит все просто, но, как правило, эти этапы длятся месяцами, а иногда годами. Все зависит от объемов, иногда УПП запускается за полгода (как правило, гораздо больше, но есть и такой приятный пример), а иногда, какой-нибудь отраслевой учет в УТ запускается больше года. Все очень сильно зависит от бизнеса заказчика и отклонений его требований от возможностей типового решения.

Для передачи эмоционального фона в процессе сдачи работ предлагаю прослушать короткую песенку о дедлайне группы Breakdown of Sanity

Ну и плюсом такую же эмоциональную картинку

В идеале, перед началом сдачи работ надо смотреть эту картинку и слушать эту музыку до достижения полной внутренней гармонии.

Основные принципы работы с клиентами остаются теми же самыми, что были описаны в предыдущих двух статьях. Нюансы, которые следует иметь в виду при сдаче работ описаны ниже.

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

На этом этапе мы фактически нянчимся с принимающей стороной.

Бывают конечно исключения, особенностью этой фазы является то, что сторона заказчика в этот период практически всегда требует разгона. Тут надо проявить лояльность и инициативу. Иногда для ускорения проведения тестирования необходимо перекинуть какое-то количество данных. Если это не особо затруднительно, мы обычно быстро накидываем правила обмена или обработки загрузки из открытых форматов типа xls или xml. Здесь важно НЕ брать полностью на себя эту работу. Даже если вы можете сделать больше, не расслабляйте заказчиков, иначе сядут на шею. Лучше договориться, что вот этот кусок мы загрузим, поможем, а заказчик сам, ручками набьет вот этот объем данных для тестирования. Как с детьми, не надо выполнять полностью их работу, но вот помочь в рамках своих компетенций — это важно. Это укрепляет связь, вы как будто бы съедаете пуд соли.

Отмечу, что это работа аккаунта! Если отдать это на откуп консультантам, то можете скоро потерять консультанта, либо не получите ожидаемой лояльности, если консультант поленится. Аккаунт, контролирует процесс сдачи-приемки, инициирует участие в переносе данных программистов, а сдает это все пользователю консультант. Лавры инициатору, исполняется чужими руками!

Общий фон этого этапа должен сигнализировать руководству и пользователям, что вам этот этап важнее, чем им!

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

Бывали и очень жесткие «прыжки».

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

Или случай, когда генподрядчик нас подставил и продавил нас на одном из этапов проекта подписаться под реализацию отчета, который назывался «Отчет по продажам». На словах отчет был «довольно простым». Сам проект был не наш и это было в самом начале нашей работы. Не было времени на достижение прозрачности, надо было косить. Поэтому, когда мы добрались до этого отчета, то оказалось, что реализация этого отчета обойдется в сумму чуть больше, чем стоимость всего проекта. Позвонив, куратору, я услышал «ну раз подписались, делайте». И снова парашют лояльности сработал отлично. Я быстро собрал внутреннюю планерку со всеми ключевыми руководителями заказчика, объяснил им, в какую ситуацию мы попали, обозначил свою готовность к сворачиванию нашего участия в проекте, если это на нас повесят и предложил им альтернативный вариант. Мы, втихую от генподрядчика, подписали простую форму отчета, которую мы сделали за полчаса в СКД. Этот отчет существенно сократил их ручной труд по составлению первоначального огромного отчета. Собственно так мы и узнали о подставе. Когда генподрядчик узнал, что мы реализовали этот кусок проекта, он с нескрываемой радостью  запросили этот отчет и на последующий вопрос «это что вообще?» я выслал скан подписанного технического задания. Оказалось, что в их системе инцидентов, заявка на этот отчет висела уже год. Естественно, в силу объемности задачи ее никто не делал.

П.С. в качестве эксперимента, я отклонился от ментальной карты. Пока я ищу свой стиль. В ментальной карте описаны только основные тезисы, которые влияют на качество, оказываемых услуг и удовлетворенность клиента.

П.П.С. я затеял вести рассылку, если вам понравился материал, вы можете подписаться на рассылку тут. Я и дальше буду продолжать публиковать материалы на ИС. В рассылке же будут практические моменты, которые не вписываются в формат ИС, но которые жизненно необходимы нашему брату.