Now Hiring: Are you a driven and motivated Mid/Senior .Net Developer?

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

Как выбрать подрядчика для разработки ПО
validation

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

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

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

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

 

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

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

 

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

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

Схематично эти взаимоотношения выглядят следующим образом.вот так.

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

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

step 1_1

 

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

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

Оценка от ИТ-подрядчиков

4. Контракт

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

Договор на ИТ-разработку

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

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

 

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

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

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

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

 

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

 

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

 

vision

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

 

Проекции системы Дубровский

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

 

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

 

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

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

Этапы начения

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

 

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

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

Разные оценки ИТ-проекта

Схема 3 — Иллюстрация восприятия объекта разработки подрядчиками.

 

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

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

 

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

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

 

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

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

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

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

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

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

 

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

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

 

Если тема анализа и выбора подрядчика для вас актуальна, то предлагаю ознакомиться с постом

 

Комментарии (10)

  1. Матвей

    В сегодняшнее тревожное текущее время, Данная публикация для меня, как глоток свежего воздуха. Пребольшое спасибо. Пожелаю Вам процветания.

    25.09.2020 at 2:39 дп
    |Ответить
    1. Алексей

      Матвей, большое спасибо вам за отзыв! В голове есть много полезных мыслей, которыми надо делиться, но никак системно пока не получается делать статьи. Такие отзывы мне помогают больше писать и более системно. =)

      29.09.2020 at 9:23 дп
      |Ответить
  2. Фаннур

    Хорошая стартовая статья для столь вечной темы. Отражает теорию в идеале.

    Было бы интересно прочитать продолжение – некое реально проведенное исследование, содержащее следующие ингредиенты.

    – Опрос хотя бы 100, а лучше 1000 потенциальных заказчиков, которые стоят на пороге создания своего “ИТ-решения”. В чём основные проблемы заказчиков, пытающихся найти подрядчиков?

    – Разница между подходами в США, Европе и России. Где больше слушают клиента и делают то, что ему нужно, а где пытаются доказать клиенту как лучше?

    – Индикаторы того, что заказчик реально знает, что ему нужно на ранней стадии. Например, наличие “бэклога”, где заказчик систематизировал результаты опроса рынка, хотя бы на 100, а лучше на 1000 конечных пользователей. А нужно ли вообще ТЗ составленное по ГОСТу? Или достаточен бриф с хорошей систематизацией результатов опроса, весами и объективно получающейся структурой и пониманием приоритетов?

    – Работа с концепцией MVP. Когда и заказчик и подрядчик понимают, что создаваемый продукт – это только начало эксперимента и проверки рабочих гипотез. Насколько введение концепции создания MVP (каким бы полным не был продукт) снижает психологическое напряжение заказчика и подрядчика от завышенных ожиданий?

    03.10.2020 at 4:24 дп
    |Ответить
    1. Алексей

      Фаннур, спасибо что прокомментировал статью. При этом дал достойный комментарий.
      Я подумаю над твоим предложением)))

      23.10.2020 at 1:05 пп
      |Ответить
  3. Сергей

    полезная статья. в дополнение к изложенному, можно посоветовать, как вариант, применять небольшие заказные исследования – spikes в терминологии Scrum – которые покажут и технологический уровень потенциального подрядчика, и позволять более точно оценить трудоемкость реализации задач на том или ином технологическом стеке.

    05.10.2020 at 9:20 дп
    |Ответить
    1. Алексей

      Сергей, спасибо за комментарий. По мне, заказные Спайки были бы конечно достаточно хорошим решением. Часто проблема возникает на этапе определения источника финансирования или простыми словами: Кто и от куда платить будет))

      05.10.2020 at 3:17 пп
      |Ответить
  4. РОМАН

    Я вот не увидел ответа на вопрос вынесенный в заголовок статьи. Если бы она называлась “Как правильно Искать подрядчика…”, тогда бы было ещё похоже. Но вот, про выбор, да ещё когда разные оценки – не нашёл(

    07.10.2020 at 3:45 пп
    |Ответить
    1. Алексей

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

      23.10.2020 at 12:48 пп
      |Ответить
  5. Юрий

    Из своего опыта (средний бизнес) убедился, что ТЗ – это совместно проработанное решение. Причём это живой документ и, вероятно, в самом начале его точность будет не более процентов 20.
    То, что имеем на этапе 1, это не более, чем набор функциональных требований.
    Ну и, абстрактно, это 3 шага, а реально выбор реального качественного подрядчика – это куча итераций.
    Совсем кратко…

    08.10.2020 at 5:26 дп
    |Ответить
    1. Алексей

      Юрий, спасибо за комментарий.
      “З – это совместно проработанное решение. ” – полностью согласен. Обращу внимание что тут важны способы проработки. =)
      “То, что имеем на этапе 1, это не более, чем набор функциональных требований.” – Тут смотря что называть этапом 1. Ну и по моему опыту набор Функциональных требований как минимум без Бизнес требований и Не функциональных требований хотя бы верхнеуровневых не даёт системного понимания продукта. Надеюсь что вы это так же понимаете.

      Смотрите, Набор функциональных требований:

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

      Если дать подрядчикам это оценивать, то кто-то будет оценивать машину, кто-то велосипед, кто-то самокат, а кто-то вообще самолёт или катер.

      При этом если добавить не функциональные требования:
      Необходимо что бы я своё расстояние от дома до офиса в 20 км проезжал не более чем за 20 минут
      Необходимо что бы ТС мог передвигаться только по дорогам так как в принципе моя дорога до офиса асфальтирована и не содержит перекрёстных переправ и т.д.
      Тут уже можно понять что Катер и Самолёт нам не нужен.

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

      Конечно пример синтетический, но мне кажется демонстративным.

      23.10.2020 at 1:03 пп
      |Ответить

Комментарии

Ваш адрес email не будет опубликован. Обязательные поля помечены *