gifts2017

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

Опубликовал boris nuraliev (nurpoz) в раздел Управление - Бизнес-процессы

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

 Схема 3

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

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

 

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

 

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

 

Планерка

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

 

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

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

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

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

 

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

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

 

------

 

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

 

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

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

дед лайн

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

 

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

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

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

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

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

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

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

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

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

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

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

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

См. также

Подписаться Добавить вознаграждение

Комментарии

1. ZLENKO.PRO (ZLENKO) 25.10.13 11:10
Наверное не совсем в тему, но думаю интересующимся темой топика будет полезно почитать это: http://habrahabr.ru/post/198868/
2. boris nuraliev (nurpoz) 25.10.13 11:18
(1) ZLENKO.PRO,
спасибо, полезная статья, почти все грабли я уже успел собрать в другом бизнесе ((
Но, боюсь, прочитай, я эту статью раньше, все равно бы все собрал.
Светлый ум; +1 Ответить
3. ZLENKO.PRO (ZLENKO) 25.10.13 11:33
(2) Вывод там очень простой - никогда ни с кем не делите бизнес, не привлекайте инвесторов. Ищите другие способы привлечения финансов и мотивации команды. Если конечно хотите чтобы это был именно ваш бизнес, а не чей то...
Очень похожая история описана в книге: Алекс Экслер "OZON.ru: История успешного интернет-бизнеса в России"
4. Евгений Сосна (pumbaE) 26.10.13 11:46
Все хорошо описано, но на один вопрос я не нахожу ответа: Где тот человек/должность/коллективный разум , который держит руку на пульсе у проекта?

Ткните носом плиз. Не могу найти, т.к.:
У программиста n задача которые необходимо сделать за конечное время. У консультанта n клиентов у части которых еще некоторые вещи не реализованы, значит можно переключится с одного клиента на другого. У о аккаунта n программистов, которые по своим задачам уточняют , m консультантов которые уточняют вопросы по работе того что сделали программисты и протестировал аккаунтер и я так понял еще есть x клиентов с которыми аккаунтер контактирует.
Из ситуации мы выгребли, густо краснея, но без каких-либо последствий.
Кто выгребает из ситуации или же приехали все 3 к клиенту (программист, аккаунтер (который должен было протестировать работу программиста), консультант) поставили программиста и сказали вот он неправ или же аккаунтера(?) и извинились?
5. boris nuraliev (nurpoz) 26.10.13 22:24
(4) pumbaE,
Уровень решения конфликта зависит от уровня самого конфликта. Если аккаунт способен сам справиться с ситуацией, то справляется сам. Если не справляется или не его уровня переговорщик с другой стороны конфликта, то он призывает меня или моих партнеров.

Для клиента мы не делаем показательных "вот это он виноват", это моя (или моих партнеров) персональная ответственность, т.к. эти все люди: аккаунты, консультанты и программеры работают под нашим началом. Поэтому в примере с ценообразованием, я бросил все, приехал, взял ситуацию под личный контроль, дождался устранения проблемы. Потом покупал дорогой алкоголь в качестве презента и приезжал лично сглаживать углы.

Аккаунты тоже люди, вот на той неделе с крупного объекта пришлось сместить человека, перестал справляться с обязанностями, хотя до этого три года отлично справлялся. Пришлось быстро отстранить его от дел. Сейчас я временно выполняю его обязанности и параллельно готовлю смену, чтобы передать дела.
6. Евгений Сосна (pumbaE) 27.10.13 14:01
(5) nurpoz, прав был Штирлиц - люди запоминают последнюю фразу.
7. Вячеслав Хахалев (Vyacheslav56) 01.11.13 10:54
Статья очень понравилась, автору спасибо!!! на рассылку подписался.
8. Алексей Белоусов (AllexSoft) 01.11.13 18:15
(0) nurpoz,
На этом этапе возникает большая часть всех выявленных недочетов. Практически всегда это связано с изменившимися за время разработки процессами или их блоками, о чем нас «забыли» предупредить.

А вот как вы выплываете из ситуаций когда изменилась казалось бы мелочь, скажем уровни детализации регистров... раньше нужно было детализировать до продавца в магазине, а стало до чека + продавец + магазин... за частую измерение то добавить не сложно, а вот логику заполнения ресурсов ой как сложно и какой то маленький отчетик который на 1 этапе либо просмотрели либо не придали ему значимости... что тогда делаете ? когда по сути надо переписывать чуть ли не пол готового блока уже на этапе сдачи?
9. boris nuraliev (nurpoz) 01.11.13 18:31
(8) AllexSoft,
Если брать, ваш конкретный пример, и мы нигде не ошиблись при формализации, то мы сядем с заказчиком за стол и начнем прорабатывать варианты, стратегию и тактику достижения новых целей. Как правило, если требования не несут серьезных экономических выгод заказчику, то подобные потребности сворачиваются на самом верхнем уровне.

п.с. недавно подобная задача как раз всплывала из-за системы мотивации заказчика, надо было "срочно-срочно", мы уже приготовились, а через две недели ввели новую систему мотивации продавцов и в подобной аналитике потребность пропала.
10. Алексей Белоусов (AllexSoft) 01.11.13 18:34
(9) nurpoz, а платит кто?) скажем вы не придали этому отчету на первом этапе значения.. "А, простой, за 5 мин напишем" .. а в итоге когда подошли к реализации оказалось не 5 мин.. то что тогда ?
А если наоборот, заказчик просто забыл про этот отчет, потому что сейчас он делается в Excel, а исполнитель болел скажем когда вы делали обследование и сбор требований... и в итоге вам показали не все что нужно... "мелочи" упустили.. кто платит ?
11. boris nuraliev (nurpoz) 01.11.13 18:48
(10) AllexSoft,
Если наша ошибка, то мы ее исправляем за свой счет. Но еще раз повторюсь, если мы придерживаемся нашей схемы работы, то критических ошибок не бывает. Все проблемы возникают, если мы отклонились от схемы взаимодействия с заказчиком.

Если ошибка/недомолвка заказчика, то платит он.

У нас действует соглашение, что все, чем оперируем, обязано быть зафиксировано и согласовано на бумаге или в электронной переписке. Если этого нет, то мы инициируем процесс переговоров, где решаем: что, как и делать ли вообще, или нет.
12. Алексей Белоусов (AllexSoft) 01.11.13 18:52
(11) nurpoz, порой заказчику не понять почему одна дополнительная колонка в отчете будет стоить как половину проекта в целом... а на ваше "она же меняет логику хранения данных и архитектуру системы" вам скажут что "это не наши проблемы, значит вы некудышные архитекторы (разработчики), делайте давайте"
13. boris nuraliev (nurpoz) 01.11.13 19:12
(12) AllexSoft,
Почитайте мою первую статью про схему. Основной принцип - понятность и прозрачность.
Мы обучаем заказчика перед тем как доходим до оценки, он к этому моменту понимает почему цена именно такая и из каких компонент она состоит. Мы всегда предлагаем точки удешевления или наоборот улучшения.
Если у вас возникает недопонимание, то его устранение это первая задача.

вам скажут что "это не наши проблемы, значит вы некудышные архитекторы (разработчики), делайте давайте"

А вот тут не все просто. Это либо саботаж, либо отжим. В первом случае необходимо двигать проблему выше, если это возможно. В случае, если уже некуда двигать или если это отжим, то необходимо иметь решительность. Это уже игры равных. Я обычно обозначаю нашу готовность выйти из проекта.
В моей практике подобные ситуации всегда были попытками отжать нас по деньгам.
14. Елена Ситникова (lesenoklenok) 07.02.14 08:58
Спасибо за данный материал, читаю уже 3 статью, все нравится и все подробно описано.
15. Георгий Фунтиков (User_Goga_patch) 13.11.15 20:54
Познавательно, с некоторым можно не согласиться а в общем спасибо за статьи .
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа