Авторская Методика MiddleMana. (В понедельник дополню)

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

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

2.      Гоните в шею разработчика не предоставляющего прейскурант на свои работы. Он должен иметь ценник. Это как сходить в ресторан без меню. Можно хорошо поужинать, но удивиться счету.

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

4.      Отправляйте к тете Дусе разработчика ,пытающегося сделать все и сразу за 2-4 парсека или 5-6 человека-лет. Покрыть 1-7 функциональных требований это лучший подход для банка.

5.      ОБЯЗАТЕЛЬНО прикиньте, какую сумму вы готовы потерять безвозвратно.

Из затрат у нас только труд специалистов. Расходами на среду разработки можно пренебречь.

Теперь про труд.

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

 А используется СВаТР (Сделай Вчера а Там Разберемся). Т.е ключевые этапы : проектирования, документирования, тестирования ,сбора и анализа попросту игнорируются. Хотя деньги на эти этапы выделяются в полном объеме. Сейчас будет крамольная мысль. Если вы банк и у вас максимум один-два разработчика, то смысла тратить деньги и время на документирование в полном объеме просто нет. Аж передернуло. Банк-это банк, а не софтверная компания, уделять огромное внимание документированию (по различным оценкам от 50-70% проектного времени) не выгодно.

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

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

Далее тестирование. Да оно важно. Но опять же если банк ( не сбер), то тестированием должен занимается поставщик программного обеспечения. Создавать тестовую среду идентичную продуктовой, просто бессмысленно, а дать разработчику маленькую копию «кусочка» продуктовой среды можно, пусть тестируется. Думаю, четырехглазое тестирование будет оптимальным в нашем случае. И главное относительно дешевым.

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

Сколько стоит создание функциональной единицы?Возвращаемся к нашему перечню и смотрим пункт 5 , посоветуйтесь маркетологами сколько стоит функциональная единица на рынке, или какие подразделения ней нуждаются, если разработка для служебного пользования. Теперь делим  одну функциональную единицу  на программные (декомпозиция на системы) получили количество разработчиков(для каждой системы свой разработчик).

 Далее делим функциональную единицу  по каждой системе, на технические атомарные операции.

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

Все, теперь считаем стоимость разработки по каждой атомарной операции, учитываем  возможные простои (про стоимость простоя я писал 87 постами ранее ). Получаем стоимость проекта по созданию ПО в банке.

Привет РМ-неудачникам.