Ну что же, вы долго и плодотворно трудились, устали, и, наконец, увидели финишную черту. В данный период, как правило, хочется уже все бросить и послать в густую чащу, и кажется, что уже ничего страшного произойти не может, завтра сдам проект и пойду в отпуск.
Но должен вас предостеречь, завершение проекта, это самое неблагодарное и из-за этого, наверное, самое сложное дело во всем проекте. Именно в это время обостряются слабые места, усиливается роль внутренних коммуникаций и порой твориться вакханалия с согласованием и принятием результатов работы, но обо всем по порядку.
Вы вышли на проверку работоспособности системы, и группа тестирования начинает давать поток ошибок и замечаний. Важно в этот момент обеспечить качественный учет, и анализ этих замечаний.
1) Ведите дневник ошибок и путей их устранения.
Во-первых, записывайте все, что приходит, досконально, предметно, адресно и вникая в причины, потом эта информация ляжет в реестр обязательных элементов для повторной проверки, и четко вырисует план устранения замечаний.
Во-вторых, после устранения каждой ошибки отмечайте, в чем она заключалась, и какие действия помогли решить проблему, это поможет в будущем, при появлении схожих ситуаций.
В-третьих, при устранении старайтесь подготавливать эталонные значения, как и в предыдущей статье. Что бы понять, что пошло не так, надо иметь представление о том, как оно должно было пойти. Кроме того это существенно сократит количество «несогласных» с результатами.
2) Предусмотрите запасной план.
Как показывает опыт пользователи не смотрят на причины возникновения ошибки, а оценивают конечный результат, выводимый вашим проектом, и если он не сходится с их ожиданием, то, скорее всего, в этом расхождении они обвинят именно вас.
Решить проблемы смежных систем своими силами, в рамках вашего проекта, у вас, скорее всего, не получится. Как бы ни был велик соблазн, создать универсальный и идеальный продукт, на выходе вы загромоздите систему надстройками, закопаетесь в проблемах, и сильно проиграете либо во времени, либо в качестве.
В условиях аврала для вдумчивого исправления ошибок требуются колоссальные ресурсы, а без них будут заплатки, которые потом обязательно дадут течь. Поэтому самым разумным выходом из подобной ситуации будет реализация механизма ручной корректировки данных, старайтесь предусматривать вариант визуального пилотирования, хорошо, если он не понадобиться, хуже, если он понадобиться, а его не будет.
3) Будьте готовы, что с первого раза ничего не заработает.
Невозможно заранее решить все вопросы на бумаге и предвидеть все варианты реализации, не всегда, все факторы бывают видны на этапе проектирования. Поэтому даже если вы точно следовали плану, нужно быть готовым, что при запуске что-то пойдет не так. Если вы уверены в людях, и проект сложный, то старайтесь заложить 20 - 30% времени на обкатку реализованных возможностей и исправления недочетов.
Это нужно понимать не только руководителю проекта, но и заинтересованным руководителям высшего звена, ставить рекорды по срокам выполнения работ это конечно хорошо, но из-за спешки чуть не развалился храм Айя София. Подходите к срокам разумно, а к проблемам с терпением, чем сложнее и амбициознее проект, тем больше он может выдать сюрпризов по его завершении.
4) Не бойтесь внедрять систему в неидеальном состоянии.
Что бы ни говорили теоретики - идеалисты, но иногда лучше запустить прототип, который в режиме живого использования будет доведен до ума, чем пытаться создать модель реального мира в лабораторных условиях, и калибровать в нем систему до идеального состояния. Скорее всего, на выходе, вы столкнетесь с такими условиями, о которых вы даже не задумывались, и система снова отправиться в лабораторию на доработку.
Этот процесс может продолжаться бесконечно, и так не найти своего практического применения, особенно если учесть тот факт, что окружающий мир тоже имеет тенденцию к изменениям.
Поэтому, если вы уверены, в том, что проект отвечает заявленным требованиям, и он способен выполнять свои функции, то выводите его из тени и нагружайте всем заявленным функционалом.
Проверить это не сложно: при тестировании заложенный алгоритм должен стабильно выдавать одинаковый и ожидаемый результат при заданных параметрах. Дальше все будет зависеть от качества и стабильности входящих данных.
5) Старайтесь тщательно описать систему.
Подробное описание методологии и инструкций пользователей помогут вам, во-первых, вспомнить, как все работает лет через пять, во-вторых, в случае выбытия кого-нибудь из членов команды (или руководителя проекта) результаты вашей работы не погибнут, и работоспособность системы в целом не пострадает.
Хорошим помощником вам станет визуализация алгоритмов и методологических принципов работы системы. Это удобно, наглядно для пользователей и поможет, по прошествии лет, снова вернуться к проекту без потери в объеме знаний.
В свое время мы популизировали методологию путем выпуска календарей с графическим изображением принципов работы той или иной системы и порядка учета некоторых операций, и дарили их сотрудникам компании. Подобная просветительская деятельность давала свои плоды, специалисты всегда имели перед глазами общую картину и быстрее привыкали к системе.
Также полезными будут обучающие видеоролики, видеоконференции и мастер-классы, старайтесь влиять на все органы чувств, тогда сможете достучаться до большей аудитории.
6) Подумайте о поощрении специалистов работающих над проектом.
Речь даже не о материальном поощрении (что тоже не маловажно), а о небольшом памятном сувенире.
Да, многие посмеются над, например, памятным значком или кружкой с названием проекта, но после завершения тяжелой работы на этот сувенир эти же люди будут смотреть с гордостью, вспоминая и рассказывая разные забавные случаи. Это как медаль, по сути, просто немного металла, но за которым стоит своя, уникальная история, а иногда целая жизнь.
В последствии, эта же команда, имеющая такие знаки отличия, будет работать гораздо сплоченней.
Но будьте внимательны, награда должна быть действительно заслуженной, иначе она обесценится.
7) Продумайте политику сопровождения системы.
Это мое субъективное мнение, но я бы рекомендовал сопровождение системы брать в свои руки и выделять под это специалистов.
Заключая договор на обслуживание и сопровождение системы, вы обязуетесь заранее учесть все спорные моменты, что сделать с первого раза практически не возможно. Вы всегда будете вынуждены доказывать контрагенту, что вы на самом деле хотели, предъявляя те или иные требования, а он вам в свою очередь будет объяснять, что он сделал все так, как понял. При этом обе стороны по-своему будут правы, и убеждены в этом.
Поэтому ресурсы, может быть, вы и высвободите, но и бестолковой работы явно прибавите, и вместо развития вы постоянно будете заниматься урегулированием споров и проверкой результатов.
Собственные специалисты конечно тоже имеют свои минусы, они дороже обходятся и их толковость вам трудно определить, но оно того стоит, по крайней мере вы всегда будете понимать что происходит, и с кого это спросить. Да и намеренного вредительства для повышения стоимости договора вы так же избежите.
А в заключении мне хочется подвести итог, одной простой мыслью, которая, как мне кажется, очень ярко отражает проблему любой новаторской деятельности: «Построить что-то новое не сложно, сложно изменить отношение людей к этому». Удачи вам!
Специально для канала Яндекс Дзен! При цитировании прошу ссылаться на источник.