Как мы работаем
Как у нас устроена работа по проекту и почему именно так. У каждого принципа мы отдельно написали, чего он не даёт.
-
01
Единица оплаты — работа
Как принято Обычно работы 1С-подрядчика считаются по отработанным часам: сколько специалист провёл за задачей, столько и в счёте.
Мы считаем стоимость от работы с описанным составом и результатом. Пришли к этому не сразу. Почасовая схема всех устраивала, пока разработка шла примерно с одной скоростью. Когда инструменты стали заметно быстрее, выяснилось, что при оплате за часы подрядчику невыгодно работать быстро, а заказчик перестаёт понимать, за что платит. Поэтому цену этапа мы фиксируем до его начала. Если работа заняла больше времени, чем мы рассчитывали, это наша проблема, а не заказчика.
Чего это не даёт Там, где состав работ заранее не описать (разбор чужого кода, поиск причины сбоя, проверка гипотезы), остаётся расчёт от часов. Назвать твёрдую цену на то, чего мы ещё не видели, честно не получится.
-
02
Обследование — отдельная работа с собственным результатом
Как принято Обычно обследование делают бесплатно, в счёт будущего договора, и его результат существует только внутри подрядчика.
Обследование мы делаем как отдельную работу: анкетирование, разбор процессов и состояния баз, целевая схема работы, состав этапов и бюджет года. Результат оформляется документом и остаётся у заказчика, даже если дальше он пойдёт с другим подрядчиком. Бесплатное обследование на самом деле тоже оплачивается, просто его стоимость заложена в последующие работы, а результат остаётся у подрядчика.
Чего это не даёт Цену проекта «на глаз» по телефону мы не назовём. До обследования любая такая цифра будет настолько приблизительной, что пользы от неё не будет ни заказчику, ни нам.
-
03
Бюджет на год по дорожной карте
Как принято Обычно заказчик просит оценить проект целиком, и подрядчик называет сумму, которая затем растёт дополнительными соглашениями.
Мы составляем дорожную карту на год: состав этапов и бюджет. Раз в полгода сверяем сделанное с картой и при необходимости меняем состав и бюджет следующих этапов. За полгода у заказчика обычно успевают поменяться и процессы, и понимание того, что ему нужно от системы, и план должен это учитывать.
Чего это не даёт Фиксированную цену «за весь проект» на годы вперёд мы не называем. По нашему опыту такая цифра либо с самого начала завышена с запасом на неизвестность, либо потом всё равно пересматривается дополнительными соглашениями.
-
04
Спецификация до разработки
Как принято Обычно задача ставится в переписке, а объём выясняется по ходу работы — вместе со стоимостью.
Разработка начинается с описания задачи: что меняем, как это должно работать и что будет считаться результатом. По этому описанию мы оцениваем объём работ и фиксируем цену этапа. Само описание оплачивается отдельно, потому что до него оценивать нечего.
Чего это не даёт Срочные правки в обход этого порядка возможны, но считаются по часам. Бывает, что исправить быстрее, чем описать, и тогда описание только мешает.
-
05
Обновляемость конфигурации сохраняется
Как принято Обычно доработки вносят прямо в типовую конфигурацию, потому что так быстрее и дешевле. Через несколько лет обновление такой базы обходится дороже, чем вся экономия.
Доработки по возможности делаем расширениями и внешними объектами, а если приходится менять конфигурацию, документируем изменения. Система должна обновляться и после нас, в том числе силами другого подрядчика.
Чего это не даёт Иногда задача не решается расширением, и конфигурацию приходится снимать с поддержки. В таких случаях мы предупреждаем до начала работ.
-
06
Пользователь — часть проекта
Как принято Обычно обучение пользователей остаётся за рамками проекта или сводится к передаче инструкции.
Обучение входит в состав работ: занятия на данных заказчика, инструкции, сопровождение в первые недели после запуска. Если пользователи вводят данные кое-как, никакая автоматизация не поможет, поэтому обучение мы не считаем необязательным дополнением к проекту.
Чего это не даёт Обучение не заменяет решения руководства. Если новый порядок работы не закреплён приказом или регламентом, пользователи постепенно вернутся к привычному, и система будет заполняться неполно.
Коротко
Ничего из этого мы не придумали сами: так работают в разработке за пределами 1С, и постепенно это приходит и сюда. Мы описали порядок заранее, чтобы заказчик знал о нём до договора, а не узнавал по ходу проекта.