Организация проекта собственной разработки ПО

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

Участники круглого стола:
Александр Бекренёв,
директор по разработке и внедрению фирмы UpScale Soft (ГК "Оптима")
Дмитрий Василевский,
заместитель начальника службы информационной безопасности,
начальник отдела внедрения и сопровождения систем обеспечения
информационной безопасности банка "Возрождение"
Виктор Горбунов,
начальник департамента ИТ, компания "Протек"
Андрей Грициенко,
начальник службы информационной безопасности банка "Возрождение"
Сергей Дятлов,
ИТ-директор ОГК-5
Александр Кутищев,
директор по производству фирмы "Спарго-технологии"
Михаил Македонский,
исполнительный директор компании "Аплана"

Intelligent Enterprise: Давайте для начала поговорим о роли собственной разработки при построении ИС в компаниях. И посмотрим, как подходить к планированию такого рода проектов. Какие факторы здесь играют ключевую роль?

Андрей Грициенко:

Собственные разработки ведут практически все банки, вынужденные постоянно вносить изменения в действующее ПО (справочники и т. п.), подгоняя документооборот под часто меняющиеся стандарты форм отчетности. Работа эта всегда срочная.

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

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

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

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

Виктор Горбунов:

Компания "Протек" существует 16 лет, и исторически разработка информационных систем имеет значительное влияние на ее бизнес. Наша основная собственная разработка - WABC, учетная торговая система. Второе ключевое приложение собственной разработки - система автоматизации работы склада STOCK, которая создавалась для конкретного технологического решения, основанного на применении радиотерминального оборудования и систем автоматизированного розничного комиссионирования

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

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

Михаил Македонский:

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

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

Александр Бекренёв:

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

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

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

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

Андрей Грициенко: Хочу заметить, что при постоянной работе в режиме цейтнота надо отдавать себе отчет, что он не исчезнет: мы так и будем работать в нем всегда. И при планировании ресурсов этот фактор нужно учитывать. Все будут самоотверженно трудиться, но 30-40% времени уйдет на отвлечения, на организационные вопросы и на документацию, на проверку ошибок, на другие проекты.

Сергей Дятлов: К тому, что было сказано, добавлю один аспект. В нашей отрасли любой бизнес-процесс цикличен. Поскольку производство непрерывное, проекты по внедрению систем автоматизации должны очень правильно вписываться в его цикл. Если не вписываешься, то уходишь уже на следующий круг, как правило, годовой. Когда мы поняли эту закономерность, то изначально спланировали проекты по разработке так, чтобы первый год был подготовительным, и к моменту, когда можно было начинать внедрение, мы вышли уже подготовленными и укладывались в допустимый период времени, включая запуск в промышленную эксплуатацию.

Каким образом вы подбираете людей в проекты разработки, как учите и мотивируете их? Как измеряете производительность их труда?

Дмитрий Василевский:

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

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

Виктор Горбунов: Трудоемкость проекта мы обычно оцениваем в человеко-часах и в степени сложности разработки. Архитектор бизнес-приложения, наиболее квалифицированный и опытный сотрудник, прикидывает, сколько времени займет эта разработка и какова ее сложность. У нас также есть система внутреннего учета рабочего времени программистов. Мы фиксируем время, которое потрачено программистом на каждую разработку, и если у него оказался превышен определенный показатель, анализируем, почему так случилось.

Что касается мотивации, то когда я пришел в ИТ-департамент, система мотивации разработчиков, ориентированная на результат, практически отсутствовала . Сейчас мы внедряем мотивацию, основанную на системе ключевых показателей. На оплату труда программиста будут влиять два параметра: сколько он сделал и насколько качественно (какое количество дефектов было выявлено при тестировании). Сейчас мы только в начале пути оптимизации ресурсов и создания системы управления производительностью разработчиков. Компания в целом занимается этапной оптимизацией затрат, а программист - это дорогой ресурс. Поэтому требуется оптимизация его загрузки как по общему объему работы, так и по характеру исполняемых задач.

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

Сергей Дятлов:

У нас начальный отбор специалистов происходит в службе управления персоналом. Они отсеивают людей, проводят начальное собеседование на психологическую устойчивость. Ведь нам нужны не только программисты, я ищу людей разных профессий. И уже после этого идёт собеседование с начальником профильного отдела, а если кандидат успешно прошел его - то со мной. Очень тяжело здесь применять какие-то численные критерии, в основном сравниваешь со своим опытом. Главный мой критерий по выбору разработчиков - чтобы человек умел решать задачи. Мне не нужен кодировщик. Я встречал людей, которые могут плодить мегабайты кода, но задача при этом решена не будет. Поэтому не вижу смысла учитывать объем кода. Бывают задачи, где не нужно программировать вообще, а имеет смысл взять какой-то инструмент из того же Office и настроить так, чтобы задача была решена. Поэтому главный критерий - умение решать задачи.
Что касается оценки работы программистов, то у нас введены KPI, которые влияют на зарплату, квартальные и годовые. Когда их вводили, встал вопрос, кто должен измерять, кто будет оценивать. После долгих обсуждений решили проводить регулярные опросы директоров - функциональных заказчиков. Показатели выработаны комплексные, довольно взвешенные, т. е. это не простая арифметика. Они периодически пересматриваются, поскольку далеко не всегда мы с первого раза угадали, какие коэффициенты лучше поставить.

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

Сергей Дятлов: Да, проблема дублирования есть. У нас большую часть таких попыток дублирования выявляет служба поддержки пользователей. Но недавно мы дали возможность разработчикам в филиалах, удаленных друг от друга на тысячи километров, тоже делать некоторые отчеты, потому что своего ресурса не хватает. Мы начали распределять проекты, координировать их, однако устранять дублирование разработанных отчетов стало сложнее. Поэтому будем вводить систему управления распределенными проектами именно как инструментарий.

Александр Кутищев:

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

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

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

В компании "Аплана" на успех и высокие показатели производительности мотивируется проектная группа целиком, а не отдельные ее сотрудники. Есть премиальный фонд, есть бонусы, но все это получает коллектив. Это очень простая система, эффективность которой проверена нами на практике. Распределение премий внутри рабочей группы осуществляется руководителем проекта. Мы исходим из того, что оценить персональный вклад каждого сотрудника лучше руководителя проекта не сможет никто. И формализованных критериев у нас для этого нет. Хотя сами руководители, насколько я знаю, некоторый комплекс своих собственных внутренних критериев используют.

Андрей Грициенко: Не стоит забывать, что любые объективные методики всегда применяют глубоко субъективные люди. И любую объективную методику можно вполне корректно применить в полном соответствии со своими субъективными соображениями, подвести свой глубокий субъективизм под строго формальное обоснование.

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

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

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

Каким образом ведется тестирование и составление документации в ваших проектах? Удается ли избежать зависимости от отдельных программистов?

Виктор Горбунов: Чтобы снизить риск утраты исходных кодов, у нас используется единая система хранения кода и система контроля версий. Разработчики не имеют права хранить код на локальных станциях или на каких-то других носителях информации.

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

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

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

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

Андрей Грициенко: У нас пользовательский функционал проверяют тестировщики. Хочу заметить, что тестировщик должен быть знаком с особенностями процесса, который он проверяет, с реальными задачами, которые решает ПО. Не думаю, что можно взять студента, ничего обо всем этом не знающего, и что он получит хорошие результаты. Тогда вам придется писать сценарий настолько детальный, что вся затея потеряет смысл. У нас есть центр тестирования, и мы пришли к тому, что тестировщиков нужно специально учить находить ошибки. Что же касается специфических особенностей приложения, то, естественно, тестировщик выявить их не сможет, и такие проверки делаются программными средствами.

Виктор Горбунов: Студенты как раз хороши в роли "человека-проблемы": находят ошибки, вызванные неадекватным поведением пользовательских интерфейсов. Но качественное функциональное тестирование они действительно выполнить не могут, поскольку не понимают, что происходит в бизнесе. В больших проектах процедуры автоматического тестирования отдельных модулей пишут сами разработчики. Кроме того, для повышения качества кода и роста профессионализма программистов у нас есть внутренний стандарт на написание кода, а также введен обмен кодом между программистами с целью ревизии. Код должен быть прокомментирован или написан настолько прозрачно, что и другой разработчик сможет в нем разобраться без особых усилий. Это тоже помогает снизить зависимость.

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

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

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

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

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

Михаил Македонский: Наша компания одновременно ведет 40 - 50 проектов, поэтому у нас несколько иной подход к стандартизации. К нашей модели разработки лучше всех подходит стандарт RUP, хотя его нам тоже пришлось несколько адаптировать. Стандарт нам очень помогает в унификации и оценке продукции. При таком количестве проектов жесткие формальные правила поставки очень важны. Это не значит, что мы регламентируем количество ошибок, при котором можно поставить продукцию заказчику. Мы констатируем необходимость отчета о тестировании и определяем его формат и содержание. В соответствии со стандартом решение о сдаче проекта принимает не его руководитель, а руководитель центра разработки на основании отчета о тестировании. Это дает возможность, с одной стороны, обеспечить определенную дисциплину поставки, а с другой - не допускать ситуации, когда версии выпускаются одна за другой, как горячие пирожки. Кроме того, такой подход позволяет управлять конфигурациями. Осознанное решение о поставке - вот что очень важно для нас, - это осознанный риск определенного числа ошибок.

Наконец, давайте поговорим о внедрении написанных систем. Согласны ли вы с тем, что процесс внедрения самописного ПО сильно отличается от внедрения тиражного продукта, что он проходит более мягко, более "человечно"?

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

Сергей Дятлов: Когда мы что-либо приобретаем, внедряем или разрабатываем, то в первую очередь смотрим, как же это будет эксплуатироваться. Процесс эксплуатации в любом случае занимает больше времени по сравнению с разработкой и внедрением, поэтому на него прежде всего и нужно ориентироваться. Для любого ИТ-проекта, особенно для заказной разработки, чтобы окупиться, горизонт эксплуатации должен составлять около десяти лет.
Тем не менее ориентация на эксплуатацию не означает, что внедрение должно быть мягким. Как показывает моя практика, "шоковое" внедрение часто более эффективно, чем мягкие, постепенные методы, важно только подготовить ресурсы, провести нечто вроде артподготовки. По моим наблюдениям более 50% продуктов, включая собственные разработки, предполагают именно шоковое внедрение. Ведь посмотрите, что такое собственная разработка. Это крик безысходности: либо вообще ничего не найдено из того, что может решить задачу, либо ничто готовое не подходит за осознаваемые нами деньги. Тут уж не до мягкости…

Дмитрий Василевский: Действительно, эксплуатация - определяющий критерий успеха внедрения. И с этой точки зрения разница между внедрением тиражного и заказного продукта не очень существенна. К такому проекту всегда нужно подходить как к процессу, который изменяет деятельность людей. В любом внедрении наиболее важен подход к людям, учет человеческого фактора. В частности, объем документации должен быть достаточным для нормальной эксплуатации, включая поддержку пользователей и внесение изменений в ПО. Софт по структуре своей должен быть удобен для сопровождения, поскольку можно сделать слабосвязанную систему, которую сопровождать будет очень тяжело, а можно предусмотреть определенные механизмы, облегчающие поддержку.

Александр Кутищев: Хотел обратить внимание еще на один аспект: успех внедрения нередко зависит от удобства и продуманности пользовательского интерфейса. Именно на основании качеств интерфейса конечные пользователи формируют свое первоначальне мнение о системе. Мы автоматизируем аптеки, и так как коллективы в них небольшие, то первое впечатление пользователей для нас крайне важно. Не секрет, что недовольство одного человека может вызвать цепную реакцию всеобщего отторжения и тем самым сильно усложнить задачу автоматизации.

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

Александр Бекренёв: Расположение элементов, насыщенность экрана элементами управления и цветовую гамму можно задать на стадии когда работают аналитики. Такие специалисты работают, ориентируясь не на пожелания пользователей, а на те функции, которые придется выполнять. И на основании этого делается заключение, какой информации достаточно, чтобы не перегружать экран, и как можно удобнее реализовать те или иные часто востребованные функции.
Однако, мы также получали от заказчика повышенные требования к удобству интерфейса. А вся формализация была в требовании "сделайте мне красиво". В этих случаях прибегали к услугам экспертов по юзабилити. Окончательную доводку под пользователя можно сделать только на этапе эксплуатации.

Сергей Дятлов: В качестве обобщения я хотел бы подчеркнуть, что нужны и внутренние разработчики, и внешние поставщики услуг по заказной разработке. У каждого есть своя ниша, свой объем задач, и нам надо сотрудничать, а не конкурировать. Иногда возникают такие споры: "Зачем вы за это сами взялись, вот вы нас наймите…". Это бессмысленный разговор. Наиболее успешные проекты получаются, когда возникает слияние внутреннего ресурса и внешнего и каждый выполняет свою работу.