Неразрешимые проблемы в управлении ИТ-проектом
Вопросы, которые мы поднимем в этой статье, относятся к индивидуальным проектам, полученным при взаимодействии исполнителя (гаранта технологий) и заказчика (гаранта ресурсов проекта), и лишь в незначительной мере к «коробочному» софту. Насколько незначительной? Догадайтесь...
Мировоззрение ИТ
Продавцы софта и ИТ-проектов создают для нас не только язык, но и мировоззрение. Маркетинговая точка зрения построена по принципу максимального отвлечения взгляда от подводных камней. Поэтому вопрос о «неразрешимых проблемах» порой оказывается неожиданным даже для опытных специалистов. Неужели они существуют?
Да, существуют, и классическое контроллинговое проектное управление в инновациях применимо с очень большими купюрами. Однако профессиональные прожект-менеджеры (ПМ) знают, что стоят денег благодаря своим дипломам по классическому менеджменту (PMI, IPMA и т. д.) и своему опыту. И хотя они интуитивно понимают, что многое, изложенное в книгах, не работает, однако явно об этом не говорят. Их риторика следующая:
-
Мы придерживаемся классического проектного управления (другого же общепринятого не существует)
-
Надо понимать, как его применять, а для этого нужен большой опыт.
Попробуем снять завесу маркетинга и разглядеть неразрешимые или плохо разрешимые вопросы инновационного управления. То есть какие-то решения существуют, но нет ни одного хорошего. Особенно интересно, что эти подводные камни остаются такими же острыми, даже если мы переходим на модные сегодня гибкие (итеративные) модели управления (XP, Scrum и т.д). Итак...
Обмен знаниями. Никто не знает, когда он начинается, когда заканчивается, в чем он измеряется. Данный процесс нельзя достоверно спланировать или проверить его статус (какая часть знаний передана). Как только все обеспечительные меры выполнены, и мы спускаемся на уровень взаимодействия стороны передающей и стороны получающей информацию, становится невозможным достоверно определить виноватого в том, что передача знаний не происходит или происходит медленно. Эта проблема была подробно описана в статье «Проблемы купли-продажи жемчуга, или Разговор о неделимых операциях» (IT-Manager, 2013, № 4). Следствием проблемы является множество негативных эффектов, например, высокая стоимость смены экспертной команды в процессе проекта.
К этому добавляется проблема проверки квалификации, которой посвящена статья «Рынок ERP: за все хорошее против всего плохого» (IT-Manager, 2015, № 8). Достоверно сказать что-либо про программиста или про консультанта можно только через очень длительный промежуток времени, например, спустя полгода. Если специалист справляется с задачей заметно медленнее, чем его коллеги, то он кандидат на увольнение. Но как это проверить, ведь каждый занимается своим направлением и задачи между собой почти не сравнимы?
Это к тому, что достоверно определить объем работ невозможно, даже после того как он выполнен. Количество физических исправлений в программе, написанных строчек кода или затраченных часов — плохие критерии. Все попытки объективно оценить деятельность, основываясь на данных показателях, наталкиваются на подгонку, которую напрямую поймать невозможно. Основная часть реального объема работ определяется временем на разбирательство в задаче, а по своим свойствам процесс напоминает «обмен знаниями». Количество часов, подлежащих оплате, определит экспертное мнение — другого способа уйти от таймшитов нет. В СССР была попытка перейти к объективной оценке. В качестве приложения к ГОСТу ЕСПД был создан Реестр укрупненных норм времени на разработку ПО, содержащий перечень типовых задач и стандартов времени. Сейчас указанный документ совершенно неприменим: «железо», среды разработки и типовые задачи сильно изменились, а нормы времени не обновлялись.
Если нельзя определить объем работ после того, как он сделан, тем более невозможно установить его заранее. Кстати, после написания программы еще придется ловить ее баги. И это тоже относится к работе по написанию программы, ведь нам нужна программа, хорошо функционирующая, а весь процесс ее создания подразумевает проектирование, разработку, тестирование, исправления по результатам тестирования, опытную эксплуатацию, внесение коррективов по итогам опытной эксплуатации. Если программа сделана добротно, то багов и проблем будет мало. А если наоборот?
Тест тесту рознь
Про тестирование стоит поговорить отдельно. Это совершенно самостоятельная неразрешимая проблема, которая рассматривалась в ключевых нестареющих ИТ-трудах: «Заметки по структурному программированию» Эдсгера Дейкстры (Dijkstra E.W. 1972. Notes on Structured Programming) и в книге «Мифический человеко-месяц» Федерика Брукса (Brooks F.P. 1975 The Mythical Man-Month). Помните историю? Правитель страны, потрясенный новой игрой (шахматами), предложил мудрецу выбрать оплату. Мудрец ответил: «Положи на первую клетку одно зернышко, на вторую в два раза больше, на следующую еще в два раза больше и так по всем клеткам». То же и с тестированием. Каждая галка-чекбокс в интерфейсе, каждый условный переход в алгоритме увеличивают количество вариантов тестирования вдвое. Брукс пишет так: «...количество тестируемых случаев растет экспоненциально». Дейкстра говорит еще проще: «Тестирование программы может служить для доказательства наличия ошибок, но никогда не докажет их отсутствие».
Следствием «проблемы тестирования» является то, что даже если программа успешно работает несколько лет, то нет никакой гарантии, что в ней отсутствуют ошибки. Не существует никаких методов, позволяющих достоверно определить наличие ошибок в программе. Точнее метод существует, и у Дейкстры он называется «доказательство правильности программы». Но в книге Брукса он не упоминается, поскольку данный метод не уровня управления, а инструмент технических специалистов. Мы им пользоваться не сможем, и при желании спецы станут водить нас за нос.
Преодолевая сопротивление
Функции, которые требуются от ПО, заранее предсказать не удастся. Большая часть статьи «Колосс на глиняных ногах» (IT-Manager, 2015, № 11) посвящена вопросу эмергентности при проектировании ПО: «ограничения человеческого воображения и мышления не позволяют заранее представить себе картину, как все будет работать, в достаточных деталях».
Эффективность использования работающего ПО невозможно измерить с приемлемой точностью, чаще всего по тому, что нельзя измерить эффективность сотрудника его использующего. Тем более нереально спланировать эффективность заранее, уже потому что все функции, которые понадобятся в ПО, мы предсказать не в состоянии.
Когда программа будет готова, вам придется преодолевать сопротивление потенциальных пользователей — они ни в какую не захотят расставаться со своими старыми методами работы и будут саботировать процесс. Причем возмущения пользователей часто могут нести в себе важную объективную истину, ведь ошибки в программе никогда не исключены. Значит, предстоит разбираться с претензиями. Смысл в письмах-жалобах будет зашифрован бытовыми, но очень путаными способами, однако нельзя их игнорировать, поскольку сбой действительно может оказаться в программе, а не в голове пользователя. Но если вы даже уверены, что он не прав, давить на него не просто, особенно если от него на предприятии многое зависит.
Впрочем, не все программы предназначены для пользователей, некоторые взаимодействуют с другими программами и оборудованием. Здесь самый сложный вопрос – отладка интеграции между программами и оборудованием. Проблема в том, что у нас взаимодействуют программы и оборудование, сделанные разными специалистами. В спорных случаях у вас не будет на руках объективных критериев для проверки того, кто же прав.
Процесс разработки/настройки/внедрения софта может быть совершенно неразделимым с точки зрения промежуточного контроля. Вместо фактических результатов контроллер увидит бутафорию, на которую к тому же добросовестный исполнитель потратит лишнее время (ибо это легче сделать, чем объяснять смысл того, что уже сделано полезного). А при недобросовестном выполнении работ контроль не обнаружит отсутствие реальных дел. Кстати, на решение именно этой проблемы заточены гибкие методологии...
Итого
Перечисленные вопросы разруливаются на уровне управления только косвенными методами. Программиста, пишущего плохой софт, через год увольняют, но год потерян. Эксперта, который врет и нашим, и вашим, тоже увольняют, но продержаться он может дольше. Объем работ определяется наугад (на новом проекте ошибка в два раза считается удачной, а в пять раз — стандартной). А чтобы выиграть тендер, в расчет берется нижняя граница, что в конечном счете приводит к переработке. Впрочем, вменяемый заказчик, понимает невозможность быстрой замены специалистов и готов пересматривать объемы работ. Заказчика подстегивает и то, что ему нужны функции программы, которые он предсказать не смог, и теперь вынужден договариваться.
Опыт профессиональных ПМ подразумевает, в частности, знание на уровне условных рефлексов перечисленных 11 пунктов. Но теперь мы вербализировали эти ощущения, а значит, их можно переоценить...
Данный материал является программной статьей в рамках публикации методологии управления инновациями «Эксперт-менеджмента». Некоторые перечисленные проблемы относятся не только к ИТ, но и к инновационному управлению в целом. Если мы не можем найти идеальное решение, то можем отыскать способ решать проблему лучше, чем это делается сейчас. Гипотеза Пуанкаре тоже долго не имела решения, к доказательству Гипотезы математики продвигались постепенно. Важно, что она была четко сформулирована.
Так и у нас. Прежде чем двигаться дальше, надо открыть глаза и признать существование препятствия, которое мешает сделать следующий шаг.
Опубликовано 11.02.2016