Неиспользуемая информация

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

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

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

Итак,

• какую информацию полезно сформулировать в начале работы над проектом?
• где и как ее получить?

Что полезно определить в начале работы над проектом?

Ниже приведены вопросы, помогающие сформировать полезную информацию. Вопросы сгруппированы в 5 разделов.

• Зачем?
• Для кого?
• Что?
• Когда?
• Как?

В некоторых случаях можно сделать выводы из одного ответа (они приведены следом курсивом). Но самые интересные выводы можно сделать из анализа ответов (и выводов из них) для разных разделов.
Например: разработчики рассматривают проект как способ изучения новой технологии ("Зачем?"), а заказчику надо, чтобы проект закончился в минимальный срок ("Когда?") и с высоким качеством (следует из "Зачем?", "Для кого?").
Однако в большинстве случаев эти выводы настолько индивидуальны, что могут показаться надуманными.
Например: заказчику надо, чтобы проект закончился в минимальный срок ("Когда?") для изменения существующей технологии ("Зачем?"), при этом у будущих пользователей отсутствуют навыки работы с компьютером ("Для кого?"), а обучение не предусматривается ("Что?").
В таком проекте сильно затягивается фаза передачи ПО пользователям.

Необходимо отметить, что все выводы требуется уточнить у пользователей и заказчиков (хотя бы в личной беседе). Учтите, что цель анализа - лучше сформулировать требования, а не упрекнуть заказчика или пользователя в неточности.

• < наименование раздела вопросов >,
• < вопрос текущего раздела? >,
• < вариант возможного ответа >,
• < возможный вывод для текущего варианта ответа >

При этом выделены следующие роли:

• заказчик - тот, кто финансирует проект или кто определяет требования;
• пользователь - тот, кто будет использовать продукт;
• разработчик - тот, кто должен предоставить результат (например, разработать ПО);
• руководство - тот (те), в чьем подчинении находятся разработчики.

Конечно же, список вопросов в каждом разделе можно расширить или сократить. Но отсутствие информации в каком-либо разделе не желательно.

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

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

Или кто заинтересован в выполнении и в окончании этой работы.

• Будущие пользователи - кто? (навыки, типы пользователей)
  • операторы, обладающие минимальными навыками работы на компьютере в ДОС или "WinДОС",
    => :
    • интерфейс должен быть функциональным и интуитивно ясным,
    • отчет должен содержать обилие примеров по использованию (типа как выполнить такую-то операцию),
    • обязательно наличие справки (help) и, возможно, в нескольких вариантах (контекстная, пункт меню, по F1),
    • желателен демонстрационный ролик с пояснениями;
  • операторы, обладающие знаниями предметной области и неплохими навыками работы на компьютере (например, физик - расчетчик, бухгалтер, ...),
    => :
    • есть возможность договориться об упрощенном отчете и интерфейсе,
    • если существует и используется аналог, использующий командную строку, то желательно ее ввести в интерфейс;
  • администратор,
    => :
    • выводы предыдущего пункта,
    • надо уделить особое внимание обеспечению прав доступа;
  • кто-то из разработчиков (делаем для себя),
    => главное функциональность, а отчет и интерфейс, может быть, могут быть упрощенными;
  • ...
• Каков интерес руководства в проведении работы?
  • чем бы дитя ни тешилось ...,
  • никто не должен сидеть без дела,
    => демонстрация процесса важнее результата
  • забота о ближнем (надо же вам на что-то жить),
  • финансовая заинтересованность (сильная или слабая?),
    => можно попробовать:
    • открутиться от других работ,
    • улучшить свое железо и используемый Soft,
    • приобрести литературу,
    • съездить подучится;
  • заинтересованность в приобретении опыта работы участниками,
    => выводы предыдущего пункта;
  • нужен флаг для выбивания финансирования,
    => :
    • выводы предыдущего пункта,
    • интерфейс должен быть ярким, рассчитанным на дилетанта (приветствуется обилие скроллеров и индикаторов выполнения),
    • желательны контекстные подсказки и анимация;
  • ...
• Кто из участников заинтересован в успешном завершении работы и почему? При этом не надо рассматривать вариант: иначе деньги не заплатят.
  • руководитель, (например, чтобы утереть нос кому-то),
  • рядовой участник проекта (например, чтобы упомянуть в резюме),
  • нет такого.
• Кто будет "толкателем" для проекта? Это тот, кто постоянно поддерживает ощущение необходимости выполнения и завершения проекта.
  • руководитель,
  • рядовой участник проекта,
  • нет такого,
    => проект может зависнуть.
• Кто еще заинтересован в успешном завершении проекта?
  • соседнее подразделение, т.к. у них ожидается подобный проект,
    => можно попробовать выторговать технику или разработчиков
  • ...

Йордон в книге "Путь камикадзе" рекомендует также выявить всех других заинтересованных в реализации и в провале проекта лиц (например, высокопоставленных лиц и др.). Но это важно в основном для менеджера (руководителя) проекта. Разработчику, по возможности, не стоит интересоваться политическими играми вокруг проекта, т.к. это отвлекает от работы.

Обычно информация этого раздела присутствует в каком-либо виде.

• Что является темой разработки?
  • Например: система анализа качества питьевой воды в различных точках водопровода города для контроля в санэпидемстанции.
• Что должно появиться как результат (состав документации, форма ПО)?
  • не определен,
    => возможны проблемы при сдаче проекта
  • ...
• Что является признаком окончания разработки?
  • передача ПО,
  • передача документации,
  • документ (например, акт о передаче),
  • не определен,
    => возможны проблемы с оплатой
  • ...
• Предполагается ли обучение будущих пользователей, и кто его организует?
• Что еще?
  • стоимость проекта,
  • вопросы оплаты,
    если не определен, то можно неприятно удивиться по окончании работы;
  • ...

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

Сроки и другие ограничения.
Например:

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

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

Или ресурсы.

• Кто участвует в разработке? Для каждого участника:
  • Каков опыт участия в подобных проектах?
  • В каком качестве может принимать участие?
  • В каком объеме может принимать участие в разработке? На какой срок, для выполнения какой работы.
  Например:
  • Иванов участвовал в подобных проектах программистом, предполагается использовать в качестве архитектора проекта, через две недели уходит в отпуск на 2 месяца.
  • Петров не участвовал в подобных проектах, имеет знания в прикладной области, предполагается использовать в качестве программиста.
  => :
  • если опыт участников невысок, то:
    • могут возникнуть проблемы со сроками,
    • возможно, потребуется обучение,
    • существует риск незавершенного проекта,
    • могут возникнуть проблемы качества, т.е. требуется более тщательное тестирование.
  • есть возможность оценить собственный дефицит времени и попытаться что-либо выполнить заранее.
• Каков инструментарий?
  • Какое ПО можно использовать (среды разработки и др.)?
  • Могут ли участники использовать привычное им ПО?
  • Предполагается ли обучение?
  Например:
  • Ограничений на используемое ПО нет.
  • Можно использовать только существующее в организации ПО и только от Microsoft.
  => :
  • есть возможность ознакомиться с каким-либо ПО заранее,
  • если отводится время на обучение, и Вам оно не требуется, - у Вас будет временной буфер.
• Есть ли наработки, готовые компоненты, идеи решения, и насколько может сократиться объем порождаемого кода и необходимое время?
  • Выполнялись ли подобные проекты ранее?
  • Есть ли прототипы для данного проекта, демонстрирующие возможность выполнения проекта?
  • Нельзя ли использовать существующие и доступные компоненты?
• Существуют ли аналоги данному проекту, и чем они не устраивают?
  => аналог можно использовать как функциональный прототип.
• Кого еще можно привлечь к работе и насколько это упростит жизнь остальным?
  Например: некто со стороны на такой-то срок для выполнения такой-то работы.

Где искать информацию?

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

Обычно информация разделов "Что?" и "Когда?" формулируется в каких-нибудь документах проекта (хотя, может быть, и не в полном объеме). Но далеко не всегда формулируется информация разделов "Зачем?", "Для кого?", "Как?". И это, не смотря на то, что с повышением сложности проекта значимость этой информации существенно возрастает.

Выводы.

Использование более полной информации о проекте просто необходимо не только менеджеру проекта (руководителю), но и разработчикам. Это помогает:

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