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

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

В тексте используются взаимозаменяемые термины «ИТ-решение» и «объект разработки». Они обозначают любое программное обеспечение (мобильные, веб-, десктоп-приложения, сайты и т.д.), которое создано в процессе разработки для достижения определенных бизнес-целей заказчика. Встречается термин «объект исследования» — стадия создания объекта разработки до момента воплощения решения.

Ситуация и проблема

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

1. Техническое Задание

Частью процесса закупки является документ с описанием решения — техническое задание (ТЗ). Менеджер заказчика — лицо, заинтересованное в услугах разработки (далее — субъект), рассылает ТЗ нескольким организациям. Субъекты в этих организациях получают ТЗ и оценивают работы на основе указанных требований. (Как у заказчика появляется ТЗ — см. в пункте “Техническое задание в студию!” на примере «близкой к идеалу ситуации»)
Схематично эти взаимоотношения выглядят следующим образом.

2. Ответ от организаций и анализ предложений

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

3. Список прошедших отбор организаций

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

4. Контракт

Подписание договора на оказание услуг с выбранным подрядчиком.


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

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

Техническое задание в студию!

Техни?ческое зада?ние (ТЗ, техзада?ние) — документ, содержащий требования заказчика к объекту закупки. ТЗ определяет условия и порядок проведения закупки, в соответствии с ним осуществляются поставка товара, выполнение работ, оказание услуг и их приемка.

Я попробую дополнить определение.

Техническое задание — это набор артефактов, через которые передаются формализованные знания об объекте закупки в данном контексте — знания о создаваемом ИТ-решении.

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

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


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


Схема 1 — Проекции рассмотрения объекта исходя из 2-го понятия системы по Дубровскому.

Останавливаться на этом подходе я не буду, но могу поделиться в комментариях опытом применения на практике, если будут запросы.

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

Как мы передаем знания о решении?

Научение — приобретение знаний, умений, навыков — происходит в несколько этапов: производство, накопление, распространение, использование.


Схема 2 — Этапы научения

Рассмотрим эту схему применительно к процессу взаимодействия с подрядчиками.

1. Производство неявного знания. Производство — это сбор информации из разных источников: рекомендации консультантов, исследование конкурентов, собственный опыт разработки ИТ-решений, информация об организации объектов вокруг исследуемой проблемы и многое другое. Неявное знание не формализовано, т.е. не выражено в каком-либо виде. Простыми словами неявное знание находится в памяти субъекта, менеджера компании, заинтересованной в разработке.
2. Накопление. Менеджер пытается формализовать неявное знание в виде технического задания. При этом, в ТЗ всегда — ВСЕГДА! — излагается не весь объём неявных знаний, а лишь та часть, которая, по субъективному мнению автора, необходима и достаточна для понимания проблематики. Любой человек, обладающий той же полнотой неявного знания об объекте исследования, прочитав это ТЗ, поймёт и проблематику, и замысел, и пути решения проблемы плюс-минус так же, как это понимает сам автор. Беда в том, что даже коллега автора из соседнего отдела того же предприятия обладает несколько иным объёмом неявного знания. Что уж говорить о представителях внешних компаний.
3. Распространение. Субъект отправляет компаниям А, Б и В часть формализованного знания. Представители компаний А, Б и В смотрят на документ и воспринимают его с учётом своей позиции в ситуации (маржинальности, требования организационной структуры, психологического восприятия и т.д.). После чего предлагают предложения по его реализации. В итоге, субъект, желая получить оценку и способ реализации одного объекта разработки, по факту получает оценки реализации N разных объектов разработки (а не разные оценки одного и того же объекта разработки).
   
   
   
   
   Схема 3 — Иллюстрация восприятия объекта разработки подрядчиками.
4. Использование. После того, как решение принято, исполнитель и заказчик корректируют ТЗ, дополняя и уточняя его в процессе обсуждения и выявления неявного знания, существующего у Заказчика.

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

Чтобы помочь менеджерам и управленцам избежать ошибок при создании и передаче ТЗ на оценку ИТ-подрядчикам, предлагаю список проекций для формализации знаний об ИТ-решении и чек-лист с описанием ситуаций, которые помогут применять описанную мной схему №2 “этапы научения”.

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

Чек-лист № 1 — “Список проекций”

1. Описание ситуации вокруг объекта в рамках деятельности на момент исследования: как люди работают, какие виды деятельности выполняют, какие сложности возникают и т.д..
2. Функциональные проекция относительно основных ролей в решении.
3. Нефункциональная проекция с моделью технических характеристик влияющих на решение.
4. Бизнес проекция относительно основных стейкхолдеров, где Цель формулируется через Способ и Результат.
5. Визуальная проекция прототипа решения (при условии, что у вас уже прошёл этап исследования на прототипе).

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

Виды ситуаций, в которых менеджер может находиться перед привлечением подрядчиков:

1. У вас есть желание сделать что-то полезное, но нет понимания, что именно.
2. Вы знаете о существовании проблемы, но у вас нет решения и вы пытаетесь выявить рассогласования. Т.е. вы проанализировали ситуацию вокруг объекта исследования, увидели элементы рассогласованности, но пока не поняли, какое именно решение и с помощью каких технологий устранит рассогласованность. Так же вы не понимаете, стоит ли вообще предпринимать действия по устранению этой проблемы.
3. Вы проанализировали ситуацию, нашли рассогласованность и поняли способ её устранения и результат, который получите. Т.е. самоопределились и поставили Цель, но пока у вас нет чёткого структурированного решения. Более того, вы столкнулись с проблемой нехватки ресурсов: компетенции, человеческие ресурсы, технологические, материальные и т.д..
4. У вас есть видение конечного решения, которое формулируется через Цели (Цель = Способ + Результат), и разработан 1-й шаг действий, структурированный относительно конечных эффектов от результатов всех Целей и проработанный относительно Чек-листа №1.
5. У вас есть решение, которое рассмотрено и определено целиком относительно минимум 4-5 позиций, указанных в чек-листе № 1.
6. Вам кажется, что вы находитесь в какой-то иной ситуации. Если это не ситуация реализации готового решения и анализа результатов, то скорее всего вы просто не поняли пункты 1-5 и вашу ситуацию всё равно можно сопоставить с этими пунктами.

Ваша задача прийти к пункту 4 или пункту 5. При этом на каждом этапе вы обязательно должны производить знания и накапливать их. У вас должны появляться как формализованные, так и не формализованные продукты вашей деятельности: схемы, описания, личный навык и опыт того, как это работает, описания через позиции чек-листа №1. И когда вы подойдете к пункту 4, то ваша задача распространить знания — передать вашим подрядчикам и партнерам.

Этап распространения чаще всего содержит в себе следующие процедуры: анализ, обсуждение и усвоение.

Если вы просто выслали ТЗ подрядчикам с целью посмотреть на цены и проанализировать составы работ, то это равносильно попытке сесть на стул, не поставив его себе под попу. Кому-то возможно повезёт и он сядет, но для кого-то будут неприятные последствия =)

Итак, задайте себе вопрос: как при передаче знаний подрядчику относительно своей ситуации вы:

• анализируете формализованные и неформализованные знания об объекте передачи
• обсуждаете совместно с подрядчиком формализованные и неформализованные знания об объекте передачи
• усваиваете данные знания.

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

Если мне нужно найти подрядчика, то поиск должен происходить через исследование подрядчиков. Следовательно, мы можем применить тот же самый системный анализ и, например, схему №1, чтобы запланировать программу по реализации данной цели. И скорее всего задачи изменятся и будут сильно отличаться от шагов, описанных в разделе “Ситуация и проблема”.