20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?"

Вступление.

Вспоминая себя после института, когда я делал первые шаги в автоматизации, я хорошо помню, как оказался в огромном вакууме неопределенности, когда мне поручили заниматься сопровождением 2-х больших систем на Усть-Илимском ЛПК (лесопромышленном комплексе). Сейчас это группа “Илим Палп”. Причем мне еще и новый для себя язык пришлось осваивать, там был FoxPro 2.5 под DOS. Я вообще не представлял, с какой стороны подходить к решению задач. Во-первых, более 500 пользователей. Во-вторых, слабое знание предметной области. А мне достались бухгалтерия и отдел кадров на 4500 сотрудников. В институте про это вообще ничего не рассказывали. Отмечу, что таких специалистов как  “аналитики/консультанты” у нас вообще не было. Предполагалось, что программист должен знать предметную область, сам получать требования у пользователя, сам их проектировать и сам доводить до пользователя. Я тогда выбрал для себя режим работы “на работе получаю информацию, дома разбираюсь”. Узнав об этом, мой куратор (наставник в роли ведущего разработчика) сказал, что это плохая практика, дома работать. Привыкнешь — плохо отвыкать. Да и не правильно это. Нужно учиться разбираться с проблемой в момент ее возникновения. Но на тот период мне выбора не оставалось, нужно было осваивать новую профессию, знаний и опыта недоставало. А ведь это была всего лишь поддержка, а не разработка.

К чему я это рассказываю? Навык быстро вникать в проблематику, привитый сразу после института в экстремальных условиях, а также осознание необходимости разбираться в предметной области не раз меня выручало в будущем. Не существовало системного обучения новых сотрудников, все постигалось “в бою”. Каждый такой новый боец добавлял в системы все больше “костылей”. Разумеется, документирования не велось.  В таких условиях браться за разработку новых систем было невозможно. О каких-либо проектных подходах я вообще молчу. К счастью, задачи разрабатывать новые системы ставились не часто, только небольшое развитие существующих, как правило связанных с изменением законодательства. В основном мы делали небольшие доработки, отчеты, печатные формы. Лишь однажды мне досталось разработать новую систему, по учету финансовых активов. Пришлось детально изучать законодательство по учету векселей. До сих пор помню. Вот что в институте изучал по большей части забыл, а что приходилось программировать — все помню.

А что мы наблюдаем в наши дни в индустрии внедрения 1С? Если не брать в расчет ТОП 20-30 крупных партнеров зачастую так и происходит — продали проект, под него быстренько собрали не сработанную между собой команду и вперед, там разберемся. Жизнь, возможно, заставляет так делать. И иногда они справляются. Но вот что в голове у еще недостаточно опытного руководителя проектов, когда он приезжает к клиенту, видит несколько многоэтажных зданий, цеха, 1000 сотрудников… И на вопрос “что нужно автоматизировать?” ему отвечают: “конечно, все!”. Куда идти, с чего начать…  В этот момент он похож на человека, который стоит на берегу океана, в глубинах которого нужно отыскать затерянный клад. И сейчас мы поговорим о том, как удобнее бороздить просторы океана, чтобы добраться до клада. Не берусь утверждать, что это просто. Также не претендую единственное правильное мнение, существуют и другие подходы, дающие хорошие результаты. Я просто делюсь своим опытом.

Начало пути в новом проекте

Если спросить специалистов, занимающихся проектами, с чего нужно начинать, можно услышать следующие варианты (что я слышал от разных РП):

• Попросить у Заказчика техническое задание.

• Применить гибкие методологии, типа SCRUM и сразу приступить к работам.

• Спросить у заказчика “что болит?”. И от этого отталкиваться.

• Провести полное обследование бизнеса, все спроектировать и потом приступать.

• Взять типовую конфигурацию, наиболее подходящую под отрасль и начать ее внедрять. Там будет видно.

• Провести экспресс-обследование и там подумать, что делать дальше.

• Поговорить с собственником, что для него самое важное, с того и начать.

• Еще возможны варианты, пишите в комментариях…

Немного прокомментирую варианты выше, есть ли среди них "истинный  путь”?

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

• Применить гибкие методологии, типа SCRUM и сразу приступить к работам. При всем уважении к гибким подходам, в данном случае это мертворожденный вариант. Опытные люди не применяют гибкие методологии на старте проекта. Почему? Потому что невозможно определить глобальную архитектуру решения, невозможно прогнозировать сроки получения результатов, ресурсы и бюджеты. Гибкие методологии могут хорошо зайти чуть позже, когда начнется стадия реализации декомпозированных этапов работ. И то, только в том случае, если ими умеют пользоваться, а не подменяют гибкими подходами обычное разгильдяйство, лень  и отсутствие управления. Успешное применение гибких методологий определяется исключительно их уместностью: в нужном месте и в нужное время.

• Спросить у заказчика “что болит?”. И от этого отталкиваться. И эту фразу я слышал не один раз. Признаться, меня от нее корежит. Голова болит у директора, когда ему такие вопросы задают. Если РП на старте начинает диалог с подобного вопроса, лучше держать его от проектов подальше.

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

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

• Провести экспресс-обследование и там подумать, что делать дальше. Пожалуй, методологически, этот вариант наиболее оптимален.  И он мне близок больше всего. Остается только раскрыть подробности, что есть “экспресс-обследование”, поскольку приведенный термин понимают не все одинаково. К экспресс-обследованию мы еще вернемся.

• Поговорить с собственником, что для него самое важное, с того и начать. Конечно, поговорить с собственником это круто, интересно и полезно. Но, в большинстве случаев, ответ на вопрос “с чего начать” получить не удастся, потому как для достижения результатов, необходимых собственнику, потребуется сделать кучу промежуточных действий и этапов. Наиболее вероятно, что он не погружается в технические детали и попросту их проигнорирует. Чтобы было понятно, приведу пример. Собственник говорит: “мне нужна система бюджетирования”. А по факту вы можете узнать, что он хочет первичные данные брать из бухучета. А в бухгалтерии вам сообщат, что нет утвержденного справочника статей и уже 2 года его сделать не получается, поскольку данные сливаются из дочерних компаний и там свой взгляд на статьи и свои директора. Договориться пока не смогли… Это простой пример, но вы поняли. Даже нормализация НСИ может стать непростым и отдельным этапом.

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

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

Итак, я остановился на следующей схеме:

1. Знакомство с задачей. Знакомство с задачей обычно занимает 1-3 дня и заключается именно в знакомстве с задачей. По-хорошему, данная информация уже должна быть у вас, еще до начала проекта. Но это если он “правильно” продавался, а если проект внутренний, то может и не быть. А даже если и продавался, вы могли в процессе продажи не участвовать напрямую. А РП должен познакомиться с задачей лично. И не важно, что там писал отдел продаж и рисовал в презентациях, если вы сами в этом не участвовали. Основные цели знакомства:

   • Задать положительный эмоциональный фон на стороне заказчика посредством демонстрации своей компетенции. Все должны быть уверены, что вы справитесь с задачей.
   • Знакомство с ключевыми руководителями.
   • И самое главное. Получить информацию для планирования экспресс-обследования. Хотя мне больше нравится термин “первичное обследование бизнес-процессов” как наиболее отражающий суть этапа.

2. Планирование экспресс-обследования. Это очень важный шаг. Проведение обследования довольно трудоемкий процесс, требующей высочайшей компетенции тех, кто его проводит. Большой ошибкой является отправлять на данную работу начинающих специалистов по принципу “все равно никто эту писанину не читает, начнем делать все будет по-другому, там разберемся”. Знакомо? Не надо так делать. Ввиду важности задачи в своих проектах я делал экспресс-анализ всегда сам. А если кого-то привлекал, то только как помощников. Очень важно ответственно отнестись и к планированию обследования, чтобы не совершать лишних действий. Нужно решить следующие задачи:

   • Какие инструменты для сбора и обработки информации будем применять.

   • Какие участки охватим, сколько специалистов нужно привлечь.

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

   • Договориться со всеми, что мы будем делать на этапе “экспресс-обследование”.

3. Проведение экспресс-обследования. Проведение экспресс-обследования сводится к выполнению работ по плану в соответствии с выбранной технологией. Почему-то многие называют экспресс-обследованием процесс “просто поговорить”. В действительности же экспресс-обследование предназначено для быстрого получения достаточной для планирования проекта информации, а также оценки необходимых ресурсов. Инструменты сбора информации при этом ничем не отличаются от детального обследования, разница лишь в глубине изучения и документирования. В целом у меня хорошо зарекомендовал себя подход, основанный на связке анкетирования с устным опросом. Разумеется, предварительно должна быть разработана технология проведения анкетирования, а также проведения опроса. Только в этом случае можно обеспечить “экспресс” — это ведь скорость, правда? Согласно правильной  технологии анкетирования, только на основании анкет даже без опросов на  выходе нужно получить:

   • Полную оргструктуру компании.

   • Подробный справочник участников, включая ФИО, должность, место нахождения, внутренний и внешний телефоны, почту и т.д., все что вам необходимо для связи. Поверьте, это очень полезная информация, особенно когда у вас 100 пользователей. А если 1000?

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

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

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

   • Перечень используемых информационных систем и баз данных.

   • Перечень Excel-таблиц и реализуемых в них задач. Жизнь показывает, что много процессов живет в Excel. Некоторые из них наверняка окажутся в рамках заявленных целей вашего проекта.

   • Перечень используемых документов и отчетов с образцами. Трудно переоценить полезность анализа выходной документации и отчетов. Она может повлиять не только на функциональность, но и на архитектуру будущей системы. 

Тактика дальнейших устных опросов при необходимости может перевести процесс “экспресс-обследования” в “детальное обследование”.

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

   • Все используемые системы (СУБД) с укрупненным описанием решаемых задач. 

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

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

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

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

Поиск точки входа.

Хочу поделиться своими рассуждениями по поводу “точки входа” в проект. Этот термин я придумал сам, просто как подходящий по смыслу. Суть заключается в том, чтобы на этапе планирования проекта, т.е. при декомпозиции работ верно определить последовательность реализации будущего проекта и найти тот участок, который будет введен в эксплуатацию самым первым. Затем просчитать самую безболезненную, а значит экономичную цепочку этапов.

Трудно переоценить важность удачно найденной “точки входа” для судьбы проекта. Я всегда долго обдумывал, принимая такое решение, глядя на 2 архитектурные схемы, о которых упоминал ранее. Этот процесс называется "построением глобальной архитектуры". И она должна быть идеальной. Неудачная точка старта может втянуть вас в бесконечные согласования, обсуждения и неопределенность. Пока будете разбираться, вера в вас как в специалистов может пошатнуться, а проект вообще закрыться.

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

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

• Меньшая нагрузка на персонал заказчика.

• Меньшая нагрузка на собственную команду.

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

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

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

• Если сможете продемонстрировать на небольшом участке свой профессионализм, дальше будете тратить гораздо меньше времени на согласование решений с руководством. Будет проще обосновывать свое мнение по предлагаемым решениям. Ведь Вам начнут доверять! Сможете добиться безоговорочного доверия заказчика, провалить проект станет сложнее, чем выполнить.

Какими принципами следует руководствоваться при поиске “точки входа”:

1. Чем меньше объем, тем лучше.

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

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

4. Удобно выделять в качестве “точки входа” систему, которая существует в отдельной базе данных, являясь частью общего интеграционного решения. Как и наоборот, оставить такой блок на последнюю очередь. Ведь он способен работать самостоятельно просто обмениваясь данными с другими системами, например с новой внедряемой.

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

Это весьма непростая задача, принять правильное решение относительно последовательности ввода в эксплуатацию. Объясню почему, а также дам советы по решению возможных проблем при поиске “точки входа”.

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

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

3. Заказчик может предъявить требования ввести в эксплуатацию сразу всю функциональность. Ну что же… Если его аргументация логичнее вашей, придется согласиться. Возможно, он готов за это и больше заплатить. Ведь и усилий придется приложить гораздо больше.  

Резюмирую.

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

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

Вот и все, надеюсь поможет, удачи всем в проектах!