Документирование — отдельная статья доходов проекта

Введение


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

Оно суть головная боль и корм для корпоративной жабы компании-разработчика. С точки зрения «типового интегратора», это некий побочный процесс, результаты которого в основном нужны для закрытия официальных требований контрактов. Не будь требований – сколько можно было бы высвободить ресурсов! Да еще и не отвлекать от работы истинных кормильцев компании: продавцов, менеджеров и в некоторой степени программистов. Картина комплектование и организации работы «мощностей» по разработке документации – отдельная грустная песня, не для этой статьи.

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

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

Уважаемые сейлы, менеджеры продуктов и проектов – давайте активнее продвигать документацию. Давайте на ней зарабатывать!

Зачем заказчику документация?

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

Универсального ответа на этот вопрос нет. В зависимости от обстоятельств, честный ответ будет варьироваться от «…й не нужна!» до «а как без нее?». Однако есть определенная зависимость. Чем продолжительнее предполагаемый период жизни и развития решения, тем важнее в нем роль документации.
Потому, что тем дольше понадобится:

Заказчику:
  • Адаптировать решение к изменяющимся реалиям в части функционала и покрытия задач. Причем быстро.
  • Расширять область автоматизации, в том числе, за счет интеграции с другими системами.
  • Учить сменяющийся (иногда – часто и много) персонал.
  • Актуализировать свою собственную нормативную базу, связанную с применением решения (регламенты, положения об отделах, технологические инструкции, должностные инструкции).
  • Вести учет, планирование и оптимизацию затрат на решение. Как минимум, чтобы знать, за что в нем уже оплачено и не попадаться ревизорам на повторной оплате того же самого с вытекающими обвинениями в двойном финансировании или отмывании.
  • Обеспечивать необходимый уровень безопасности предприятия – в том числе, посредством исключения зависимости от единственного поставщика/разработчика критично важного решения.

Исполнителю:
  • Передавать компетенции по разработке решения (за 2 года сменится половина команды «в теме», дальше – больше).
  • Передавать компетенции по обеспечению качества и сопровождению решения – тестировщики и персонал поддержки меняются еще быстрее.
  • Актуализировать информационное обеспечение для менеджера продукта.

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

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

Другой довольно весомый аргумент, связанный со сроком службы решения – его стоимость в расчете за определенный период времени. Учитывая, что стоимость решения для заказчика «в год» составляет сумму всех расходов, деленную на количество лет, его штатная жаба должна быть кровно заинтересована, чтобы знаменатель в этой формуле был как можно больше. Одно дело, если система за 6 млн. проработает 2 года, и совсем другое, если хотя бы 3. Это целый миллион экономии каждый год.

Конечно, разработчики могут возразить «Ну и что? Мы просто наваяем через два года год еще одно решение за такие же деньги. Нам же лучше!». Но, во-первых, это не спортивно. А во-вторых, срабатывает ограниченное количество раз, после чего найти заказчика становится сложнее.

В завершение разговора про значимость срока службы приведу следующую мысль-наблюдение. Вдруг пригодится как аргумент познания ценности в сравнении. В системе, эксплуатируемой 6-8 лет, программный код переживает несколько рефакторингов и раз-другой переписывается с нуля (причем нередко другим исполнителем и на других технологиях). А вот документы, описывающие потребности заказчика и основные способы их удовлетворения, разве что пару раз актуализируют. Слегка.

Что предложить Заказчику?

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

В большинстве случаев, включая проекты для коммерческих структур, при определении номенклатуры и содержания документации можно отталкиваться от связки ГОСТ 34.201-89 и РД 50-34.698-90. Не лишним будет также заранее поинтересоваться наличием у заказчика собственных ведомственных или корпоративных стандартов (или даже личными предпочтениями лица, принимающего решения).

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

Могу предложить следующие категории, которыми пользуюсь сам:

1. Предпроектная. В нее войдут документы, которые предшествуют проектированию решения. В том числе:
  • отчеты об обследовании;
  • концепции;
  • технико-экономические обоснования;
  • технические задания и т.п.
Польза от них часто бывает там, где заказчик сам не полностью владеет ситуацией и желает знать, что происходит, например, в его филиалах. Или желает еще раз основательно подумать, следует ли ему начинать серьезные работы (за исключением ТЗ, о нем ниже).

2. Проектная. Все, что относится к проектируемому (но пока еще не реализованному) решению. Проектных документов может быть довольно много (см. например, тот же ГОСТ 34.201-89) и от проекта к проекту акценты полезности и привлекательности тех или иных документов для потенциального заказчика могут смещаться, однако наиболее востребованными обычно являются документы, содержащие описание:
  • задач, которые автоматизирует предлагаемое решение;
  • технических подробностей о функционале и внутреннем устройстве решения;
  • необходимых действий для того, чтобы проектируемое решение могло заработать «как положено» (стратегия миграции данных, план обучения персонала, аттестация рабочих мест и т.п.).
Польза, во-первых, в понимании заказчиком того, что задумали исполнители и оценке ожидаемых результатов на относительно ранней стадии. Во-вторых, в понимании объема предстоящих работ и их соответствия средствам и срокам. В третьих, относительная независимость от единственного разработчика. Ну и еще кое-что по мелочи.

3. Рабочая. Сюда относим сведения о том, как спроектированное решение должно быть размещено/настроено/снабжено первоначальной информацией во вполне конкретных условиях работы. В том числе:
  • схемы размещений технических средств на объекте автоматизации;
  • схемы подключения питания и каналов связи;
  • описания конфигурационных файлов;
  • описание первичного наполнения справочников и баз данных;
  • описание методов диагностики и т.п.
Бесценно, если заказчик планирует эксплуатировать и сопровождать решение своими силами (как минимум, частично).

4. Эксплуатационная. Все, что объясняет, как работать с решением. В первую очередь, это различные руководства, инструкции и технические регламенты. В отличие от проектной и рабочей, в полезности эксплуатационной документации заказчика убеждать приходится редко. За исключением случаев, когда заказчик получил глубокую эмоциональную и душевную травму от предыдущего употребления результатов работы горе-писателей.

5. Административно-регулирующая. Если решение предполагает вмешательство в оргструктуру заказчика (от изменения отдельных функций и переподчинения отдельных сотрудников, до изменений на уровне иерархии организации), то такие события в солидных конторах сопровождаются документально. И редко когда Заказчик горит желанием выполнить эту работу сам. Это веский повод предложить облегчить его и без того тяжкую ношу (и бюджет, разумеется). К документации этой категории можно отнести:
  • административные регламенты оказания услуг или осуществления функций;
  • регламенты функционирования подразделений;
  • положения о структурных подразделениях;
  • проекты приказов, которыми вводятся те или иные организационные изменения;
  • должностные инструкции и т.п.

6. Обучающая. Я умышленно отделяю ее от эксплуатационной. Сюда предлагаю относить материалы, организованно подготавливающие персонал заказчика к выполнению своих задач при помощи нашего решения. Особо важное значение эти материалы имеют в условиях высокой текучести персонала (колл-центры, кассы розницы и т.п.). К обучающим можно отнести:
  • программы обучения и контроля полученных «студентами» знаний;
  • методические материалы;
  • учебные курсы (в т.ч. аудио-видео).

7. «Разное». В зависимости от ситуации, может возникнуть потребность (или желание) разработать документы, которые сложно однозначно отнести к какой-либо из перечисленных выше категорий. Например, протоколы информационного взаимодействия между заказчиком и сторонней организацией обычно имеют признаки одновременно административной, проектной и рабочей документации.

Особо хочу остановиться на двух документах. «Вырвать» их из контекста. Это:
  • Техническое задание, в котором в самом начале работ определяются рамки проекта и основные требования к решению.
  • Программа и методика испытаний, подписывая которую, заказчик подтверждает, что предусмотренные в ней испытания полностью отвечают его ожиданиям от реализации требований ТЗ (вплоть до уровня целей и задач). Другими словами, он официально подтверждает, что предложенная на испытания система – именно то, чего он хотел.
Вот эти документы, по моему скромному мнению, нужно иметь в любом проекте в бумажном виде со всеми согласующими и утверждающими подписями.

Как предложить Заказчику?

На эту тему написано очень много и гораздо лучше, чем могу написать я. Мой скромный опыт лишь подсказывает, что при наличии более-менее грамотного специалиста по документированию, ничто не мешает:
  1. Подготовить максимальную, оптимальную и минимальную комплектацию пакета документов, которую можно обоснованно предложить Заказчику в конкретной ситуации.
  2. Грамотно и системно обосновать достоинства каждого из предлагаемых пакетов и каждого из входящих в него документов. Составить сравнительную таблицу.
  3. Культурно оформить все это в разделе технико-коммерческого предложения.


Вместо заключения...

… поделюсь историей про номенклатуру документации и потребности заказчика.

Как-то довелось участвовать в разработке серьезного решения для весьма серьезного заказчика. Когда увидел требования, немного удивился: в них была прописана разработка порядка 35+ документов технорабочего проекта. То есть, практически весь 34-й ГОСТ.

На осторожный вопрос «Зачем вам все это богатство?» заказчик ответил примерно так: «Конкурирующий отдел из соседнего Управления только что принял систему, которую укомплектовали 20-ю документами. Мы не можем допустить, чтобы в глазах генерала наша разработка выглядела менее солидно!».

А вы говорите – «не продается!»
Поделиться публикацией

Комментарии 14

    +1
    Надо было начать с истории, которая в конце… и ей же закончить.

    Объемная документация на ПО в наше время закрывает только одну потребность — «чтобы в глазах генерала наша разработка выглядела менее солидно!». Причем состав документации в этом случае не имеет никакого значения.

    Если покупатели — коммерсанты, то им в 95% случаев нафиг не нужна документация. И как бы вы не расписывали её полезность, она не закрывает реальные потребности. Если же потребности есть, то заказчик и сам попросит подготовить необходимый комплект документов.
      0
      Заказчик не всегда является большим специалистом в автоматизации, и не всегда понимает, что ему нужно. Собственно, поэтому он и платит исполнителям.

      Если потребности нет, то:
      а) надо объяснить, зачем нужна документация, и создать потребность.
      б) не надо заморачиваться с документацией.

      В каждом отдельном случае решение принимать ответственным за это сотрудникам.
        0
        В отличие от b2c рынка, где потребность можно создать за счет эмоций и сиюминутности, на b2b рынке для создания потребности надо вложить очень много денег, и то не факт что получится.
        Кроме того под эту потребность надо будет экономическое основание писать, на слово обычно не верят. В этом случае типы документации 1-5 пролетают почти полностью, ибо ни экономии затрат, ни повышения доходов они не создают, и даже если их удастся продать, то не более чем 10% от общей суммы проекта.
          0
          «В отличие от b2c рынка, где потребность можно создать за счет эмоций и сиюминутности, на b2b рынке для создания потребности надо вложить очень много денег, и то не факт что получится.»

          В целом да, согласен — чаще всего это именно так. Но иногда бывает достаточно объяснить преимущества ответственному лицу. И если шанс есть — почему бы им не воспользоваться?

          «Кроме того под эту потребность надо будет экономическое основание писать, на слово обычно не верят.»

          В технико-коммерческом предложении таким обоснованиям самое место. Я даже привел в статье часть из того, что можно использовать.

          «даже если их удастся продать, то не более чем 10% от общей суммы проекта.»

          В последние несколько лет мне редко доводится участвовать в проектах с бюджетом менее 100 млн. рублей. 10% этой суммы — это немало. :)

          * * *

          Кроме того, «продать» можно не только за деньги. Продать можно в качестве замещения другой проектной работы, которую делать не хочется или не можется. («Не, давайте без этой фичи. А взамен мы вот такую инструкцию напишем!»)

            0
            Сначала хотел откомментить все, но потом прочитал это:
            В последние несколько лет мне редко доводится участвовать в проектах с бюджетом менее 100 млн. рублей

            Понял что госы. Но там другие правила игры. В отличие от бизнеса госы не заинтересованы ни в снижении затрат (бюджет все равно надо весь потратить, иначе дадут меньше), ни в увеличении прибыл (ибо нет прибыли), ни в расширении рынка (ибо нет рынка). Зато документация очень важна, потому что начальству надо бумажки показывать. И чем больше бумаги, тем лучше.

            Я вот участвовал в госпроекте. Суммарные затраты на «документацию» составляли 60% бюджета проекта. При этом документация не нужна никому вообще.

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

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

              «Но в коммерческой разработке ни разу не было, чтобы удалось продать документацию.»

              Было два раза. По мелочи, правда. И один раз два директора и один менеджер проекта на совещании получили взбучку от коммерческого заказчика за халатность по этой теме. По существу взбучку. Документы наваяли, но не те и не так.
                0
                Было два раза. По мелочи, правда. И один раз два директора и один менеджер проекта на совещании получили взбучку от коммерческого заказчика за халатность по этой теме. По существу взбучку. Документы наваяли, но не те и не так.

                То есть по факту один удачный раз и тот «по мелочи». Получается вы сами опровергаете суть своего же поста.

                Думаю вам стоит сфокусироваться именно на вопросах документирования для госов — что и как писать, как сократить затраты на написание ГОСТовских документов. Я бы с удовольствием почитал такую статью.

                Эта статья получилась в общем неверная. Увы.
                  0
                  То есть по факту один удачный раз и тот «по мелочи


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

                  Количество «раз» не суть важно. Я утверждаю, что эту работу вполне можно вести с результатом, отличным от нуля даже в коммерции. А вести или нет — это каждый уполномоченный решает по ситуации.

                  Я подумаю над предложением «сфокусироваться». :)

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

                  Готово. Быстро и недорого.

                  Если говорить чуть серьезнее, то объем методички по написанию ТЗ по ГОСТ 34 у меня составил 44 листа. Это явно не формат хабростатьи (кроме того, права на нее принадлежат организации, которая за нее заплатила). И цель методички — помочь в написании качественных документов, а не сократить расходы на их подготовку.

                  В любом случае — благодарю за высказанное мнение и его обоснование.
        +2
        Ой не люблю я выносить такие обсуждения из личек, но в ответ на просьбу исправить англонизм «сейлы»:

        «Я не занимаюсь переводами на английский, прошу извинить.
        Я применяю устоявшуюся в предметной области терминологию, прошу также извинить.»

        Я считаю хамством. А последнее — откровенным враньем. Я не знаю авторитетных рускоязычных авторов, употребляющий термин «сейлы» в понимании «продавцы», ибо сленг, граничащий с грубостью.

        Если хотите, это как сказать, что «либераст» — устоявшийся термин.
          –1
          Ну, раз уж вынесли — нужно было выносить и тот текст, на который был дан этот ответ. Заодно показали бы мне «просьбу исправить англонизм «сейлы»». Возможно, я ее не заметил.

          Могу назвать навскидку 3-4 интегратора из топ-20, в которых этот термин употребляется каждый день (в чем я имел и имею возможность убедиться лично). Общая численность персонала в них — более 5 тыс. человек. Считаю даже такую аудиторию достаточной, чтобы назвать термин «устоявшимся».
          Это не выходя за пределы отрасли ИТ.

          Сожалею, что незнание авторитетов дает Вам основания для обвинений кого-либо во вранье.
            0
            Сожалею, что вы не различаете разговорного сленга и письменную речь. А также скорблю о вашей слепоте: употребляется сейл (sale) вместо селлер (seller), вы одушевленного человека низводите к бездушному предмету. Вы до сих пор уверены в своей правоте?
              0
              сэйлзы это… и всем сразу понятно…
                0
                Я просто не понимаю, зачем Вы это пишете. И пишете в публичной области. Это кому-то интересно?

                Хотите меня убедить, что в английском слово «sale» отличается от «seller»? Охотно верю.

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

                Хотите меня убедить, что не следует употреблять разговорные выражения в тексте статьи? Возможно, но это прошу оставить на мое усмотрение и направить педагогические усилия в более конструктивное русло.
                  +2
                  " Возможно, но это прошу оставить на мое усмотрение" —

                  Забавно, вы аппелируете к свободе слова, в тоже время требуя объяснить почему я реализую свое право. Хорошо, я намекну.

                  В правилах Хабра есть такой пункт:
                  «Хабр — для грамотных людей. Мы любим русский язык и не любим тех, кто его коверкает.»

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое