Мобильная        
   PDA-версия  


интеллектуальная группа

KIBORG . net



@   О КОМПАНИИ

@   УСЛУГИ

@   КОНТАКТЫ

      AXAPTA / 1С

      MRP / CRM

      УПРАВЛЕНИЕ

-   ОБУЧЕНИЕ

V   СТАТЬИ

-   ПУБЛИКАЦИИ

#   ЛУЧШИЕ

-   ИССЛЕДОВАНИЯ

-   ТЕРМИНОЛОГИЯ




С т а т ь и



o   ПО ДАТАМ
o   ПО ЖУРНАЛАМ

o   ERP
==== >>   УПРАВЛЕНИЕ
o   СИСТЕМЫ





() Управление предприятием

() Департамент ИТ

(+) БИЗНЕС-КОНСТРУИРОВАНИЕ

() Инновации






 
 

ERP   /\/   Управление   /\/   Системы     (Лучшие)


Управление - ДИТ - Инжиниринг - Инноватика



Проблематика IT-управления (полный перечень)


Неразрешимые проблемы в управлении ИТ-проектом

 

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

из к/ф "Чародеи"
печатное издание IT-Manager, май 2016 г.

Маркетинг ломится к нам из всех СМИ и как ни странно формирует наш ИТ-язык. Возьмем, к примеру, термин "Коробочное решение", который собран из двух: "Отраслевого решения" и "Коробочного программного продукта". Известные всем массовое коробочное ПО содержит очень мало ошибок: на конкурентном рынке выживает только качественный софт. Интеграторы, в попытке продать свои отраслевые решения, идут на маркетинговый подлог, называя их коробочными. Постепенно красивые термины приживаются.

Вопросы, которые мы поднимем в этой статье относятся к индивидуальным проектам, которые получаются при взаимодействии исполнителя (гаранта технологий) и заказчика (гаранта ресурсов проекта) и лишь в незначительной мере к коробочному софту. В какой именно незначительной? Догадайтесь…

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

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

  • Мы придерживаемся классического проектного управления (ха, другого же общепринятого не существует);
  • Надо понимать, как его применять, для этого нужен большой опыт.

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

  1. Обмен знаниями: никто не знает, когда он начинается, когда заканчивается, в чем он измеряется. Этот процесс невозможно достоверно спланировать. Невозможно проверить его статус (какая часть знаний передана). Как только все обеспечительные меры выполнены, и мы спускаемся на уровень взаимодействия стороны передающей и стороны их получающей информацию, то невозможно достоверно определить виноватого в том, что передача знаний не происходит или происходит медленно. Эта проблема была подробно описана в статье Разговор о неделимых операциях. Следствием этой проблемы является множество негативных эффектов, например, высокая стоимость смены экспертной команды в процессе проекта.
  2. К этому добавляется проблема проверки квалификации, которой посвящена статья За все хорошее, против всего плохого. Достоверно сказать, что-либо про программиста или про консультанта, можно только через очень длительный промежуток времени, например, через пол года. Если с задачей специалист справляется заметно медленнее чем его коллеги, то он кандидат на увольнение. Но как это проверить, ведь каждый занимается своим направлением, и задачи между собой почти не сравнимы?
  3. Это к тому, что достоверно определить объем работ невозможно, даже после того как он выполнен. Количество физических исправлений в программе, количество написанных строчек кода, количество затраченных часов являются плохими критериями. Все попытки объективной оценки работ по данным показателям наталкиваются на подгонку, которую напрямую поймать невозможно. Основная часть реального объема работ определяется временем, на разбирательство в задаче, а этот процесс похож по свойствам на "обмен знаниями". Количество часов, подлежащих оплате, определят экспертное мнение, другого способа уйти от таймшитов нет. В СССР была попытка перейти к объективной оценке. В качестве приложения к ГОСТу ЕСПД был создан реестр Укрупненных Норм Времени на разработку ПО, содержащий перечень типовых задач и стандартов времени. Сейчас этот документ совершенно не применим: железо, среды разработки и типовые задачи сильно изменились, а Нормы Времени не обновлялись.
  4. Раз невозможно определить объем работ после того как он сделан, тем более невозможно определить его заранее. Кстати, после того как программа будет написана, еще придется ловить ее баги. Этот объем работ тоже относится к работе по написанию программы, ведь нам нужна программа, работающая хорошо, а процесс написание такой программы подразумевает: проектирование, разработку, тестирование, исправления по результатам тестирования, опытную эксплуатацию, исправления по результатам опытной эксплуатации. Если программа написана хорошо, то багов будет мало и проблем будет мало. А если наоборот?
  5. Про тестирование стоит поговорить отдельно. Это совершенно самостоятельная неразрешимая проблема, которая рассматривалась в ключевых нестареющих ИТ-трудах: "Заметки по структурному программированию" Эдсгера Дейкстры (Dijkstra E.W. 1972. Notes on Structured Programming) и в книге "Мифический человеко-месяц" Федерика Брукса (Brooks F.P. 1975 The Mythical Man-Month). Помните историю: правитель страны, потрясенный новой игрой (шахматами) предложил мудрецу выбрать оплату. Мудрец ответил, - положи на первую клетку одно зернышко, на вторую в два раза больше, на следующую еще в два раза больше и так по всем клеткам. Так и с тестированием. Каждая галка-чекбокс в интерфейсе, каждый условный переход в алгоритме увеличивают количество вариантов тестирования в два раза. Брукс пишет так: "…количество тестируемых случаев растет экспоненциально". Дейкстра говорит еще проще: "Тестирование программы может служить для доказательства наличия ошибок, но никогда не докажет их отсутствие".
  6. Следствием проблемы тестирования, является то, что даже если программа успешно работает несколько лет, то нет никакой гарантии, что в ней нет ошибок. Ни существует ни каких методов достоверно определить есть ли ошибки в программе. Точнее метод существует, и у Дейкстры он называется "доказательство правильности программы". Но в книге Брукса этот метод не упоминается, по тому, что этот метод не уровня управления, это инструмент технических специалистов. Мы им пользоваться не сможем, и при желании спецы смогут водить нас за нос.
  7. Все функции и свойства, которые требуются от ПО заранее предсказать невозможно. Большая часть статьи статье Колосс на глиняных ногах посвящена вопросу эмергентности при проектировании ПО: "ограничения человеческого воображения и мышления не позволяют заранее представить себе картину, как все будет работать в достаточных деталях".
  8. Эффективность использования работающего ПО невозможно измерить с приемлемой точностью, чаще всего по тому что, невозможно измерить эффективность сотрудника его использующего. Для большинства полезных эффектов ПО не существует методик расчета. Тем более, невозможно спланировать эффективность заранее, уже по тому, что все функции, которые потребуются в ПО мы предсказать не сможем. Это, компенсируется тем, что получаемая польза настолько значительна (по ощущениям и частичным расчетам), что многие готовы рисковать.
  9. Когда программа будет готова, вам потребуется преодолеть сопротивление пользователей, которые ни в какую не захотят расставаться со своими старыми методами работы и будут саботировать процесс. Этому вопросу посвящены статьи Роль и риски руководителя компании, CRM и парадоксы управления, Электрофикация работника и Жеские меры мягкого CRM.
  10. А бывает еще и спор специалистов. Когда программы взаимодействуют с другими программами или оборудованием, то отладка такой интеграции вопрос весьма непростой. Коммуницирующие изделия созданы разными специалистами. В спорных случаях у вас не будет на руках объективных критериев проверки того, кто же прав.
  11. Контролировать все детали не возможно. Чем больше контроля, тем больше бутафории. Процесс разработки/настройки/внедрения софта, совершенноо неразделим на этапы. Как нибудь разделить, конечно можно. А смысл? Вместо фактических результатов контроллер увидит потемкинские деревни, на которую, к тому же добросовестный исполнитель потратит лишнее время (ибо это легче сделать чем объяснять смысл того что уже сделано полезного). А при недобросовестном выполнении работ контроль не сможет обнаружить отсутствие реальных дел. Кстати, на решение именно этой проблемы заточены гибкие (Agile) методологии…

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

Опыт профессиональные ПМ подразумевает в частности знание на уровне условных рефлексов перечисленных 11 пунктов. Но теперь мы вербализировали эти ощущения и значит их можно переоценить… Эта статья является программной статьей в рамках публикации Методологии управления инновациями "Эксперт-менеджмента". Некоторые перечисленные проблемы относятся не только к ИТ, но и инновационному управлению в целом. Если мы не можем найти идеальное решение, то можем найти способ решать проблему лучше, чем делается сейчас. Гипотеза Пуанкаре тоже долго не имела решения, к доказательству Гипотезы математики продвигались постепенно. Важно, что она была четко сформулирована.

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

 

 

 

2016 г. Мартынов Дмитрий

 

КОПИРАЙТ

Статья разрешена к копированию любыми средствами без изменения содержания с обязательным указанием автора, источника и гиперссылки на оригинал:

гиперссылка html:
гиперcсылка для форума/блога:

 

Консалтинг по управлению ИТ проектами.
-  Аудит, анализ и тренинги


Экспертиза ....
Интеграция ERP, MRP, CRM, SCM систем
-  Настройка, обучение, доработка.



Внедрение ....
Бизнеспроцессы: описание в стандартах IDEF, ARIS, EPC, On-Target



Бизнес-анализ ....
Оптимизация бизнеса. Внедрение, электронного документооборота
-  Управление ответственностью и рисками.



Мотивация ....
Разработка регламентов управления с использованием ИТ.
-  Повышение стабильности и эффективности работы отделов.


Реорганизация ....
Гарантии качества подтверждены опытом наших экспертов.
-  Все наши специалисты сертифицированы.



Сотрудничество ....


 
  О компании    Услуги    Контакты    Axapta        Обучение    Управление   

    © 2005, ООО "Интеллектуальная группа Киборг"   PDA-версия