Зависимость между управленческим циклом менеджмента и жизненным циклом разработки ПО

Свое первое профессиональное образование я получал в колледже по направлению 38.02.04 "Коммерция (по отраслям)" (да, да, согласно диплому СПО, я квалифицированный менеджер по продажам 😎), но при этом я всегда работал в IT-сфере, причем в основном в разработке. В какой-то момент, на себе пришлось прочувствовалась всю проблему того, что мало разработать какой-то качественный коммерческий продукт, нужно на этом заработать — а это тоже целая наука.

Хочу сказать, что я неоднократно вспоминал добрыми словами Шкобырева Анатолия Федоровича, преподавателя, который очень увлеченно вел у нас множество дисциплин, в т.ч. "Менеджмент", по которому я и хочу затронуть тему.

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

1. Анализ;
2. Проектирование;
3. Разработка;
4. Внедрение.

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

Управленческий цикл менеджмента

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

1. Планирование. При планировании мы определяем цели создания,возможности, а также все возможные пути и средства достижения этих целей.
2. Организация (глагол). На этом этапе решается кто руководит, кто разрабатывает и как происходит все взаимодействие.
3. Мотивация. Удивительно, но именно этот этап часто игнорируется, либо считается малозначимым у типичных "эффективных менеджеров". На этом этапе нам надо все что организовали побудить к эффективным действиям.
4. Контроль. При этом этапе контролируется соответствие ожидаемым результатам и в случае отклонений, корректировки вносятся через планирование, т.е. в новой итерации цикла.

При планировании огромную роль играет корректная оценка своих возможностей.

Главное отличие между желанием и возможностями в том, что желания безграничны, а возможности всегда ограничены.

В итоге, специфичной задачей становится реализация корректного взаимодействия жизненного цикла разработки ПО и управленческого цикла.

Пример управленческого цикла в виде часового механизма

Давайте представим весь этот управленческий цикл в виде часового механизма. Целью этого механизма является предоставление информации о текущем времени.

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

На этапе организации — мы строим сложный рабочий механизм шестеренок и стрелок. На этом этапе фактически формируется весь механизм, но он еще не работает и не показывает время! Эту проблему решает этап "мотивации" — эта именно та движущая сила, которая заставляет работать весь механизм. Севшие или незаведенные часы - это и есть организация без мотивации, т.е. это просто безжизненный механизм, ничего более.

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

Управленческие функции: планирование, организация, мотивация и контроль - применимы к любому объекту управления.

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

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

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