Когда страшно, что всё получится. Первые упражнения менеджеров RnDm

Вчера прочитал первое занятие со студентам ВМиК МГУ по курсу "Управление проектами разработки и исследования". Для меня это первый шаг в сторону докладов не-про-ИБ. Также новым были детства чистые глазёнки доверие аудитории и внимание с которым воспринималось всё сказанное - это налагает значительно большую ответственность, в сравнении с проведением тренингов или выступлениями на конференциях.

Курс я делаю максимально практическим и интерактивным для своей же пользы. Уже на первой вводной лекции удалось вытащить дать возможность рассказать о своих проектах каждому участнику, дать несколько практических инструментов на попробовать дома. В результате - есть первый интересный результат беглого анализа проектов (а почти у всех это курсовая/дипломная работа со сроками в апреле-мае). Оказалось довольно типичной проблемой тянуть с решением задачи, в которой даже при большом объеме работ минимален уровень риска, под давлением страха от неопределённости и рисков следующей задачи (этапа).



Яркий пример: надо реализовать программу, предлагающую сервис пользователю (человеку), при этом совершенно не ясны методы оценки качества её реализации (экспертная оценка сокурсника всё ещё не ок?).

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

Чем ближе (по % выполнения) пугающая контрольная точка завершения программной реализации, тем дольше хочется оставаться в безопасном состоянии выполнения понятных задач. Более того, подсознательно (и довольно оправдано, кстати) зреет убеждение, что выше шансы успешной сдачи проекта, если в конце будет продемонстрирован героизм реализации, нежели безуспешные попытки согласовать результаты испытаний. Таким образом проект зависает на 80% готовности и "доедает" отведённое время до жесткого крайнего срока.

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

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

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