Тест для самопроверки руководителя проекта: как отличить падавана от рыцаря-джедая?

12.01.23

Управление проектом - Компетенции и навыки РП

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

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

Сокращенная модель предполагает упрощенный взгляд на вещи. Наши маркетологи призывают меня предложить решение в формате “Ответь на 10 вопросов теста, и поймешь, насколько ты крутой руководитель проекта”. А я не могу. Потому что, честно скажем, это будет попросту говоря фикция. 
Потому что проекты бывают разные, контексты бывают разные и практически ни на какой вопрос теста “как стоит вести себя руководителю проекта?” нельзя дать однозначно “правильный” и “неправильный” ответ. 
Типичный вопрос из этой серии был опубликован на сайте белорусской Школы управления Алексея Минкевича. Я иногда даю его на своих курсах, и он сразу вызывает бурную дискуссию:

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

Варианты ответа:

  • А. Попросить архитекторов сосредоточится на вопросах, имеющих более высокий приоритет, чем система отчетов. Напомнить им, что вопрос о системе отчетов встанет только в следующем квартале.
  • Б. Поговорить с архитекторами о важности единства и командного духа, похвалить их профессионализм и снять напряженность, проведя командообразующее мероприятие.
  • В. Выслушать обе точки зрения, определить лучшую из них и запустить ее в работу.
  • Г. Выслушать точки зрения, понять разницу в предлагаемых решениях, попросить архитекторов обсудить вопрос вместе и помочь прийти к согласованному мнению.

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

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

А. Попросить архитекторов сосредоточится на вопросах, имеющих более высокий приоритет, чем система отчетов. Напомнить им, что вопрос о системе отчетов встанет только в следующем квартале.
Действительно, мы же не можем позволить себе обсуждать неактуальные вопросы! Тем более, что почти наверняка дедлайны жесткие, команда работает, возможно, в авральном режиме.
 
Б. Поговорить с архитекторами о важности единства и командного духа, похвалить их профессионализм и снять напряженность, проведя командообразующее мероприятие.
Важно переключить людей с больной темы, на что-то другое!

В. Выслушать обе точки зрения, определить лучшую из них и запустить ее в работу.
Это самый реалистичный из вариантов. Работать как-то надо, а уже видно, что договориться у участников не получается. А руководитель проекта скорее всего наиболее компетентен из членов команды.

Г. Выслушать точки зрения, понять разницу в предлагаемых решениях, попросить архитекторов обсудить вопрос вместе и помочь прийти к согласованному мнению.
С точки зрения авторов теста, именно этот вариант ответа является правильным. 
Аргументация: здесь мы предлагаем участникам прийти к консенсусу, то есть найти решение, которое устроит обе стороны. Как гласит первый закон фасилитации (да простят мне это ругательное слово), люди гораздо охотнее реализуют решения, проработанные и принятые с их участием. Поэтому вариант “найти решение проблемы” (Г) оказывается более выигрышным, чем А (уклонение), Б (сглаживание), В (принуждение). Вариант А, на самом деле, выглядел бы логичным (если проблема правда встанет только в следующем квартале), если бы не одна деталь в тексте:  “Из 8 пунктов повестки не удалось принять решение ни по одному пункту, хотя обсуждение набора технологий для отчетов вообще не входило в повестку собрания” - команда уже потеряла работоспособность, ждать следующего квартала не вариант.


Пожалуй, я согласна с тем, что последний вариант наиболее выигрышный (если он сработает - честно скажем, гарантии совсем нет). Но, повторюсь, я легко могу представить себе контекст, в котором скорее сработают другие варианты ответа. И так будет с практически любым вопросом по существу управления проектами. Разумеется, если не брать вопросы типа “Что относится к принципам Скрам?” или “Какие процессы в управлении рисками выделяет 6-ой PMBOK Guide?” которые прямо не проверяют умение решать рабочие задачи.

Но наглядную модель компетенций сделать все-таки хочется. Конечно, сразу предупреждаю, что она будет упрощенной и неоднозначной. Важно понимать все ограничения такого упрощенного теста - что он описывает не все ситуации. Но по принципу Паретто “80 на 20”, полагаю, что в 80% он все-таки попадет. То есть в большинстве случаев позволит отличить чайника от профи. 

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

 

В чём фокус?


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

Поэтому в предлагаемом тесте я предлагаю делать следующее:
Определить, какие проблемы являются самыми больными
Оценить, насколько с какими проблемами вы умеете справляться и какими инструментами в этой сфере владеете
Сравнить первое и второе. 

В качестве основы модели я взяла 8 доменов исполнения из 7-ого PMBOK Guide (Руководство к Своду знаний по управлению проектами). 

В качестве вариантов - путь развития джедая:

  • Младший джедай
  • Падаван
  • Рыцарь-джедай
  • Мастер джедай

А в качестве проблем - то, с чем сталкиваются многие руководители проектов.  В частности:

Команда    

  • В команде не очень понятно, кто за что отвечает
  • Люди разбегаются из команды
  •     Конфликты в ходе работы
  •     Информация теряется в ходе работы
  •     Новые лидеры не вырастают, команда требует микроменеджмента
  •     Люди незамотивированы в проекте
  •     Обмена знаниями в команде не происходит

Заинтересованные стороны    

  •     Бизнес-заказчик не доволен результатом проекта
  •     По итогу понятно, что за проект вообще не нужно было браться
  •     Проекту вставляют палки в колеса
  •     Пользователи не заинтересованы во внедрении
  •     Пользователи не готовы ставить требования
  •     Конфликты между бизнес-заказчиком и разработчиками
  •     Разные ожидания у разных участников

    
    
    
Подход к управлению проектом и жизненный цикл проекта    

  •     Происходит много отклонений от составленного в начале подробного ТЗ
  •     Приходится делать много лишней работы из-за смены требований
  •     Проект не укладывается в сроки и бюджет

    
    
Планирование    

  • План проекта не соответствует действительности
  •     Проект выбивается из расписания
  •     Проект не укладывается в бюджет
  •     Возникают конфликты из-за ресурсов

    
    
    
    
Измерение    

  • Не очень понятно, на какой стадии какие работы находятся
  •     Одни и те же ошибки повторяются по несколько раз
  •     Отчеты содержат недостоверную информацию

    
    
Работы по проекту    

  • Не всегда понятно, какие задачи уже выполнены, а что еще нужно сделать
  •     Люди перегружены задачами
  •     Результат оказывается несогласованным

    
Поставка    

  • Требования нарастают как снежный ком
  •     Заказчикам не нравится результат даже когда их требования выполнены в полной мере
  •     Заложенным в системе бизнес-процессам потом никто не следует
  •     Результат оказывается никому не нужным, так как выдается слишком поздно

    
Риски    

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


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


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

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

См. также

Как быть эффективным руководителем проекта, а не экскурсоводом для команды стейкхолдеров

Компетенции и навыки РП Бесплатно (free)

Статья о том, как быть эффективным руководителем проектов. Кто такой руководитель проектов, что подразумевает эта роль в проекте, и зачем она нужна?

22.03.2024    401    0    PChizhov    0    

5

Управление проектом Руководителем проекта со стороны Заказчика

Компетенции и навыки РП Взгляд со стороны Заказчика Бесплатно (free)

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

26.02.2024    775    0    user1270271    0    

11

Нужно ли аналитику 1С знать конфигурирование?

Компетенции и навыки РП Работа с требованиями Бесплатно (free)

Аналитики 1С не всегда хорошо представляют себе, в каких таблицах системы хранятся данные, и из каких объектов состоит конфигурация. Как следствие – технические задания часто получаются непонятными для разработчиков. Расскажем о том, зачем аналитику разбираться в таких темах, как конфигуратор и структура метаданных, регистры, запросы, СКД, интеграция и обмен данными.

02.02.2024    1182    0    otkalo    1    

6

5 основных внутренних ограничений руководителя

Компетенции и навыки РП Бесплатно (free)

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

22.01.2024    965    0    andmakarov    2    

13

Риски, роли, книги и светлое будущее для ПМов: проектный дайджест #35

Компетенции и навыки РП Обучение и наставничество Инструменты управления проектом Бесплатно (free)

Что интересного писали про управление проектами за прошедшую неделю? Мы прочитали все публикации vc, Хабра, Инфостарта (и не только) и выбрали самые крутые и полезные.

09.10.2023    804    0    Birby    0    

1

Методика оценки задач или Как «не угореть» по срокам

Компетенции и навыки РП Бесплатно (free)

Часто на проекте внедрения нужно понять, сколько времени уйдет на ту или иную задачу. От правильности расчета зависит, успеет ли разработчик сделать задачу в оговоренные часы или будет перерабатывать по ночам, и останется ли заказчик доволен стоимостью и сроками. Расскажем о простой методике расчета трудоемкости задач, которая позволит добиться оптимальных оценок и укрепить лояльность заказчика.

31.08.2023    2243    0    Midzgun    4    

12

Практика построения проектного офиса в ИТ-компании

Компетенции и навыки РП Бесплатно (free)

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

18.08.2023    2219    0    Pryamonosov    2    

6

Национальные особенности управления

Компетенции и навыки РП Бесплатно (free)

Внедрение проектного управления в России и странах СНГ пробуксовывает, и причина этому – национальные особенности, в том числе национальные особенности управления. Перечислим пять основных особенностей, которые мешают системно использовать проектные подходы в России, расскажем о том, как с этим работать и что поможет предотвратить риски.

17.08.2023    1423    0    paalferov    2    

18
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. dklimchuk 44 12.01.23 20:53 Сейчас в теме
Какие гадкие маркетологи...
2. MariaTemchina 1594 12.01.23 22:34 Сейчас в теме
(1) Маркетологи не гадкие! Маркетологи полезные! Они заставляют включать мозг, и думать, куда дальше расти и чего развивать!..
starik-2005; +1 Ответить
3. Aphanas 92 13.01.23 05:30 Сейчас в теме
Не совсем понятно, как можно "попросить архитекторов обсудить вопрос вместе и помочь прийти к согласованному мнению", если "Каждый из специалистов провел исследование и доказывает, что нужно выбрать именно его набор технологий." Тут либо одно, либо другое.
Если можно прийти к согласованному мнению, значит кто-то не провел исследование.
dima_home; Светлый ум; +2 Ответить
12. MariaTemchina 1594 13.01.23 13:12 Сейчас в теме
(3) Руководителю проекта предлагается выступить в роли фасилитатора. То есть помочь людям, имеющим разные точки зрения, прийти к общей. В реальности эта задача имеет решение гораздо чаще, чем может показаться. Очень часто конфликты возникают из-за недостатка информации, из-за разных предпосылок, из-за непонимания функционала другого решения и т. п. Иногда можно интегрировать оба предлагаемых решения, или разделить их функционал. Или хотя бы провести взвешенную оценку возможностей каждого решения - возможно, архитекторы на этом месте договорятся.

Это возможно далеко не всегда, согласна. Но чаще, чем может показаться на первый взгляд.
16. booksfill 13.01.23 14:23 Сейчас в теме
(3)
Если у обоих сторон есть реальные аргументы, нужна научная дискуссия, когда сторонам важно найти правильное решение, а не перекричать другого.
А для это нужен кто-то третий, у кого нет времени самому искать факты, зато есть авторитет и умение разбираться в приводимых аргументах.

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

Поэтому из приведенных вариантов я не выбрал бы ни один, а "заставил" автора вариантов ответов их конкретизировать, до тех пор, пока он сам не поймет, что конкретно имелось в виду. Если ему так важно основание, то напомнить про правило 5-и почему (от Сакити Тойода)
4. CheBurator 3119 13.01.23 07:29 Сейчас в теме
ИМХО. РП тоже надо когда-то по каким-то вопросам посоветоваться и получить консультацию. Когда проектов много - бывает трудно получить доступ к "супервайзеру/архитектору", потому что он постоянно занят и тоже работает по проектам, а не развитием продукта вне текущих задач проектов...
5. DemetrKlim 157 13.01.23 08:51 Сейчас в теме
Из моей юности:
... Юноши, зачем газон косите?
- Чтобы красиво было.
- А почему вы - в противогазах??
- А мы, дядя - комсомольцы! мы без трудностей не можем!
....
Коллективы программистов начали напоминать типовые наборы персонажей из психологических тренингов на собраниях анонимных алкоголиков или арахнофобов, каких-нибудь. Или из детских игр в "дочки-матери" или "больницу". "...Давай, ты будешь медсестрой, а я - доктором..."
Не, ну реально, так же! "Давай, ты будешь архитектором, а я аналитиком..." И мы долго будем трещать про всякую фигню о всякой фигне на наших... как это... Митапах!
Опять же, из моей юности... Туда, куда раньше приходили программисты, персонал развивался и умнел. "Подтягивались" руководители, получившие новый прогрессивный инструментарий контроля и управления. Сейчас ситуация "отразилась в зеркало". Тупеньким менеджерам и управленцам понадобился аналогичный уровень кодеров. Логично же! Умников никто не любит, поэтому, ребятки, давайте вы тоже потупеете на наш манер! В самом деле, чтобы сейчас писать под диктовку текущего менеджмента, программисту надо хапнуть оглушающую дозу кретинизма, чтобы не получить ментальный инсульт, прочитав очередное "техзадание" на очередной "управленческий отчет".
atseparate; vakham; Andreev.a; Tigreno; morin; rozer; maksa2005; eskor; +8 Ответить
11. eskor 98 13.01.23 12:37 Сейчас в теме
(5) Полностью согласен. Уже несколько лет наблюдается тенденция массового отупения социума.
Старая гвардия практически исчезла с горизонта, новая не появилась. Зато появились всевозможные PM Book и еще с ними.
Под эту идею команды растут бешеными темпами, при этом эффективность падает с ростом количества.
А самое прикольное, когда пытаются выстроить количественную оценку разработчиков, аналитиков и архитекторов, там начинается самая дичь.
vakham; Andreev.a; +2 Ответить
6. starik-2005 3033 13.01.23 10:35 Сейчас в теме
Проблема русских студентов в том, что они на 100% доверяют кому-то, кто по их мнению авторитет, и на 100% не доверяют тому, кто этим авторитетом не является (ну или однажды "согрешил"). Например, кто-то может на 100% доверять автору этой статьи, совершенно не включая "думалку", а кто-то другой будет отрицать это же самое, также "думалку" не включая. Слишком уж мы верим своим авторитетам, слишком уж нам сложно "думалку" включать - за нас же все уже придумано ("Все украдено до вас!" (с)). Ну и слишком уж мы "злопамятны" (ну или злые и память хорошая).
7. dklimchuk 44 13.01.23 10:40 Сейчас в теме
(6)это свойственно не только русским и не только студентам :) отсутствие навыка критического мышления, анализа и синтеза свойственно 90% людей.
9. starik-2005 3033 13.01.23 11:08 Сейчас в теме
(7)
это свойственно не только русским и не только студентам
Я тут не спорю. Просто привел мнение нескольких преподавателей иностранцев, работавших в ВУЗах РФ. Они давали "детям" разобрать несколько текстов, попросив выделить сильные и слабые стороны аргументации авторов. В итоге "дети" в большинстве своем или критиковали все "почем зря", или "пели оды". Т.е. большинство студентов не справилось с отделением зерен от плевел. При том "другие" студенты (не из РФ) с такими заданиями справлялись не в пример лучше. Видимо, особенность. Это видно по статьям Белокаменцева - ему просто определенный народ минусы ставит, особо не разбираясь (часто даже не читая).
Vyacheslide; vakham; dklimchuk; +3 Ответить
8. cdiamond 233 13.01.23 10:41 Сейчас в теме
а где самые ходовые варианты:
- выбрать решение броском кости;
- выбрать предложение А, потому что архитектор красивая девушка
- выбрать предложение Б потому что архитектор мужик
- посчитать кто из архитекторов дольше работает и имеет больше удачных решений
и.т.д., потому что ваш "правильный" вариант с точки зрения бизнеса ни в коей мере даже близко не правильный, потому что ручным управлением занимаются только "незаменимые" руководители.
Andreev.a; Dimanchik00; MariaTemchina; +3 Ответить
13. MariaTemchina 1594 13.01.23 13:15 Сейчас в теме
(8)
ение А, потому что архитектор красивая девушка
- выбрать предложение Б потому что архитектор мужик
- посчитать кто из архитекторов дольше работает и имеет больше удачных решений
и.т.д., потому что ваш "правильный" вариант с точки зрения бизнеса ни в коей мере даже близко не правильный, потому что ручным управление


Эти ходовые варианты входят внутрь варианта "самому выбрать правильное решение".
Кстати, слышала про руководителя, который, когда подчиненные приходили за советом, прямо при них подбрасывал монетку и говорил ответ. Результат - подчиненные быстро перестали приходить. Цель - развитие самостоятельности у команды - была достигнута! )))
10. sapervodichka 6697 13.01.23 11:50 Сейчас в теме
Заповедь Джедая:

Всегда старайся понять причину своего гнева: порой он вполне обоснован и даже необходим для дела, но иногда служит только индикатором непонимания тобой ситуации.

Да прибудет с тобой сила.
maksa2005; MariaTemchina; eskor; +3 Ответить
14. MariaTemchina 1594 13.01.23 13:15 Сейчас в теме
(10)
Мне кажется, эту заповедь будет полезно взять на вооружение практически любому РП...
15. awk 741 13.01.23 14:20 Сейчас в теме
А где вариант уволить одного из?
Нет ну серьезно. РП не владеет (да и не должен владеть тех. знаниями), так что понять какое решение лучше он в принципе не может. А вот дать ребятам 15 минут договориться, а потом методом подброса монетки уволить одного из - это вполне реально... Если оба ведущих не дураки, то любое из решений не будет катастрофичным.
17. titanium2008 42 13.01.23 18:30 Сейчас в теме
Сам архитектор и еще ни разу не видел толкового РП в чистом виде! В итоге я РП и архитектор.
Чтобы разнять двух архитекторов, должен быть главный архитектор!
22. MariaTemchina 1594 17.01.23 14:32 Сейчас в теме
(17) В том как раз и заключается идея фасилитации, что для того чтобы помочь людям договориться необязательно быть специалистом в предметной деятельности. Проверено на практике.
26. vakham 19 19.01.23 12:53 Сейчас в теме
(22)А у меня когда-то был начальник, который предметной областью не владел... И вообще пока я его ни разу не видел (хотя коллеги говорили, что он есть).

А ещё знаю одну региональную компанию, в которой маркетолог-руководятел ИТ так замотивировал программистов, что они на кулачках выясняли "ху из ху". Сурьёзная компания, пердовые мэтоды управления.
18. roman72 379 13.01.23 20:12 Сейчас в теме
Задача РП не выступить фасилитатором двух архитекторов,
тратя время на очередные бесплодные споры и меряние архитектурными....эээ... излишествами,
а выработать объективный формализованный критерий,
по которому оба предложенных архитекторами решения проверяются
и отбрасывается решение не соответствующее критерию.
Или оба.
23. MariaTemchina 1594 17.01.23 14:33 Сейчас в теме
(18) Это хорошее решение, да. Вместе придумать критерии, проверить оба предложения, и выбрать результат. Кстати, это как раз один из методов фасилитации ))) (действенный, но не единственный).
19. DemetrKlim 157 14.01.23 12:57 Сейчас в теме
Меня терзают смутные сомнения, что термин "архитектор" кто-то слямзил из фильма "Матрица". До выхода этого фильма я ни разу не слушал употребление слова "архитектор" применительно к IT-сфере.
Вот этот перебор терминов "архитектор", "аналитик", "руководитель проекта" (скоро появится какой-нить "IT-жрец"!) я перевел бы на русский понятный язык таким образом - "Коллеги! Нам нужен хоть кто-то, кто понимает что мы вообще делаем!!" Вполне могу понять эту насущную потребность, ведь даже в субтитрах голливудских боевиков мелькает такая должность, как "постановщик боев", ибо любая коллективная деятельность без предварительного сценария и оперативной режиссуры выглядит несуразной свалкой, никак не впечатляющей зрителей. В фильмах Тинто Брасса тоже были постановщики задач... э-э-э групповых сцен)
Я когда представляю себе коллектив программистов, то сразу вспоминаю мультик "Миньоны", когда бодрая толпа милых, трудолюбивых, усердных созданий так же усердно искала себе м-м-м... Мастера, Сеньора, Хозяина, Дирижера, Вождя... Да как угодно можно назвать! Того, кто даст коллективу усердных тружеников хоть какое-то направление для реализации их энтузиазма и жажды деятельности) А без такого вождя дружный изначально коллектив милых миньонов превращался в колготящуюся, мешающую друг другу, кишащую толпу.
И судя по количеству разных курсов, митапов и прочей совещательной риторики, огромное количество кодеров еще не обрели в своих коллективах таких вождей, которых они решили называть "архитекторами".
Если серьезно, то по моему мнению, это дело несуразное. Поясняю. Когда люди не понимают сути процесса, они имеют два варианта решения этой проблемы. Первый, вроде бы самый логичный, потратить какое-то время и силы на изучение незнакомого процесса. Второй, более быстрый и от этого - соблазнительный, создать свою "Вселенную Марвела", где ранее непонятный процесс будет вновь воссоздан уже с понятными терминами, процессами и участниками. Смысловые разрывы в такой волшебной вселенной декорируются волшебными же заклинаниями, не имеющими отражения в реальности, но вполне оживающие в условиях сказочности. Пример. Население земли очень долго не понимало - что гремит и сверкает на небе во время дождя. Поэтому тысячи лет небеса "населялись" богами, духами, прочими сверхъестественными существами, отвечающими за звуки грома и отправку молний... А потом пришли Ломоносов с Франклином и нафег разогнали с небес всю эту тьму сказочных существ, просто вогнав в землю молниеотводы. И как же они это сделали? А очень просто - они процесс изучили, никак не изобретая при этом всяких виртуальных сущностей и явлений! Применительно к учетным задачам это выглядит так. Можно изучить бухгалтерский учет, как универсальный инструментарий, и его текущую нормативную базу. Попутно ознакомиться с Гражданским и Трудовым кодексами. А можно произнести волшебное заклинание "оперативный финансово-управленческий учет" и в эту фразу уместить всю новую вселенную, ничего при этом не изучая (ибо - нечего изучать!)
Я считаю программирование (в части учетных задач) совершенно нетворческим делом. Коллеги, мы ничего не создаем! Мы - описываем уже существующую конструкцию! И тут, опять же, два варианта. Либо мы заранее знаем чертежи этой конструкции, либо нам нужен то, под чью диктовку будем писать. Всё! Я бы только добавил, что самое глупое, при этом, писать под диктовку будущего пользователя. Ибо он надиктует вам как раз те проблемы, для решения которых вас, накануне, и пригласили. И что же делать архитектору (человеку очень творческой профессии!) там, где для творчества остались только цвета интерфейсных окон? Да нефига ему делать, от слова - совсем. Если только не поместить архитектора в свою сказочную вселенную, где такой мастер будет бесконечно перекладывать кирпичики управленческого учета, скрепляя их раствором, замешанном на бизнес-процессах. А потом придет другой архитектор, злой, и два архитектора начнут кидать друг в друга всякие шипящие молнии и прочие HTTP-запросы, разрушая друг у друга хлипкие фундаменты управленческих учетов. А автор сказки будет сидеть и, пригорюнившись, думать - как ему помирить двух распоясавшихся архитекторов, нечаянно встретившихся в его рассыпающейся вселенной...
А теперь цитата из святой Википедии:
"Бри́тва О́ккама (иногда ле́звие О́ккама) — методологический принцип, в кратком виде гласящий: «Не следует множить сущее без необходимости»[1] (либо «Не следует привлекать новые сущности без крайней на то необходимости»)....."
Так вот. Не плодите несуществующие сущности - просто процесс изучите, а то программисты уже потерялись в толпе консультантов, аналитиков, архитекторов и руководителей проектов. Профессионалы понимают друг друга с полуслова и у них редко бывают принципиальные разногласия (это же не союз кинематографистов!). Если вы не знаете, как прекратить споры двух "архитекторов", есть простое решение - увольте обоих!! А программистов заставьте изучить ту предметную область, в которой они подвизаются. Это решит 99% проблем.
sofa07; user596529_a-ivashenko60; vakham; Andreev.a; user1739750; awk; +6 1 Ответить
24. MariaTemchina 1594 17.01.23 14:34 Сейчас в теме
(19)
Профессионалы понимают друг друга с полуслова и у них редко бывают принципиальные разногласия (это же не союз кинематографистов!).

А вот с этим, кстати, не согласна! У профессионалов по моему опыту как раз часто бывают принципиальные разногласия - потому что в природе бывает больше одного правильного способа что-то делать!...
25. DemetrKlim 157 17.01.23 16:23 Сейчас в теме
(24)И вот тут надо определиться в терминах. Вы очень молодой человек (и это прекрасно!), а я помню время, когда экраны и страницы журналов заполонили "профессионалы". Знаете, кто? "Потомственный маг пятого уровня", "Ведьма в девятом поколении", "Народный целитель клана Велеса шестого круга коловорота". У нас в тот период статус академика медицинских наук получил откровенный шарлатан, собирающийся, ни много ни мало, оживлять мертвых!! А уж моя пресловутая "землячка" Света Пеунова, так до сих пор "в обойме" и на слуху, правда, уже без рептилоидов. Кстати, вы еще помните этих водителей газелей со специфической внешностью горячих южан? Так, как гоняли по дорогам они - не умел больше никто! Автобусы ставили на два колеса! Они себя считали профессионалами! "Я с пяти лэт за рулом!!!" Почему-то их соседи по дороге так не считали)
Итак, первое, кого мы назовем профессионалами?
Невозможно быть профессионалом без конкретной профессии. Понятно, что внутри профессии присутствуют специализации, никак не выходящие, при этом, "за края" общепрофессиональной базы. Наличие профессии обязывает ее обладателя находиться на какой-то платформе. Платформу формирует профессиональная нормативная база. Стоя на общей нормативной платформе, вы не имеете даже шансов на долгие споры. Вы часто слышали споры водителей - можно ли ехать на красный свет? Кому и кого пропускать при помехе справа?
Электрики никогда не спорят о правилах электробезопасности (они их просто наизусть однажды выучили и это стало спинно-мозговыми рефлексами!). И все остальное, в той или иной степени, так же!
Любую профессию (кроме совсем уж творческих) формирует нормативная и правовая документация, которая в свою очередь вырастает из соответствующей этой профессии научной базы, как медицина базируется на общей биологии. Собственно, профессионалами принято называть того, кто подробнее, тщательнее и крепче изучил свою профессиональную платформу.
И вот тут самое интересное! У программистов таки есть своя собственная нормативная база! И я сроду не слышал, чтобы кто-то ей руководствовался, обсуждают любые химеры, кроме действующего нормативного документа - загадка! Более того, эту нормативную базу обновили впервые после 1997-го года. и с 01.01.2021 эти изменения вступили в силу! Но так называемое "профессиональное сообщество" вообще никак на это не отреагировало. Такое ощущение, что разработчики упрямо топчут свою лыжню и ищут собственную формулу философского камня. А там все ответы как раз и есть! Надо просто принять содержимое этого норматива как руководство к действию и сделать это своими практиками - жизнь начнет налаживаться. Почему Мерседес в Берлине ездит быстрее, чем такой же Мерседес в Каире? Потому, что в Берлине Мерседес ездит по правилам!) А можно потратить жизнь в поисках и разработках своих собственных правил, долго обсуждая темы "как помирить спорящих архитекторов"))
Это длится потому, что пока заказчик еще не набрал компетенций, многих заказчиков, как коней в поводу, пятилетками кружат по адовым кругам "внедрений и обновлений". А потом заказчик вынужден будет поумнеть (неумных просто отпылесосит с рынков). И тогда никого не будут интересовать все эти задушевные споры "архитекторов и аналитиков" со своим РП. Профессионалы от заказчиков захотят работать с аналогичными профи от IT-сферы. А любой реальный профессионал достаточно быстро определит, кто перед ним - профессионал, работающий в каких-то нормативных и предсказуемых рамках, или вечный "творец прекрасного", работающий по наитию непредсказуемо долго и без предсказуемого результата.
dikar40; user596529_a-ivashenko60; Andreev.a; +3 Ответить
20. pma_2015 129 17.01.23 11:43 Сейчас в теме
(19)
1. Ломоносов и Франклин: «они процесс изучили, никак не изобретая при этом всяких виртуальных сущностей и явлений». Разве? А откуда тогда раздел физики Электромагнетизм? Михаил Ломоносов издал первый в России учебник физики, нет?
2. Бритву Оккама еще и применять надо уметь. «Не следует множить сущее без необходимости». Но если необходимость есть – множить очень даже можно. И нужно. У вас главный посыл, что этой необходимости нет. Но вместо аргументов - лирика.
21. DemetrKlim 157 17.01.23 12:35 Сейчас в теме
(20) Весь смысл моего текста в том и состоял, что я очень хочу уйти от лирики. И всех к этому призываю. Но я же не мог писать о лирике без лирики. Я не могу серьезно писать об эльфах, гномах и магах - лирика сама напрашивается.
Применительно к Ломоносову и иже с ним. Титаны, создающие новые отрасли научных знаний. Как может создать целый раздел физики тот, кто этот раздел сам еще не изучал? Что должны были знать эти великие люди? Как они дошли до такой степени гениальности, что из "ничего" слепили фундаменты великих знаний? Что они изучали - ВНАЧАЛЕ? У этих исторических персонажей было одно - общее, практически, все они изучали - ФИЛОСОФИЮ, как способ критического осмысления и обобщения фактов, изучали логику, как инструмент владения философией, и изучали математику, как универсальный язык всех наук. Кем был изобретатель бухгалтерского учета? Принято называть имя Луки Пачоли. Конечно, он не один был, но первое системное знание сформировал он, как принято считать (я не специалист в историях - могу и не знать подробностей). Лука был философом и математиком. Он создал математически обоснованную, логически - безупречную, философски - целостную систему учета. Он создал, как принято говорить научную школу или платформу. Создание новых научных школ - удел гениев и титанов мысли. Даже изучение их наследия - это труд и время. И что же делают сейчас? Потомки, в целях экономии времени, интересно распорядились наследием гениев. Многие из них радостно прочитали пару непонятных брошюр, купленных на развальчике рядом с гороскопами, после чего все наследие гениев отправили в мусорные корзины. Нафига нам эти ветхозаветные "Домострои", щас мы накодируем новую реальность! Ну, и чо? Накодировали? Сравнились с титанами? Создали научную школу того же управленческого учета? И чьих имен будет авторство?
Отсюда и все эти споры "архитекторов" и "аналитиков". Для продуктивного спора надо сначала найти какую-то общую платформу с едиными правилами, системой координат и оценок показателей ,в рамках которой спор будет иметь смысл и перспективу разрешения. В геометрии Эвклида параллельные прямые никогда не пересекаются. А в геометрии Лобачевского допускается их пересечение. Один архитектор учился у Эвклида, второй - у Лобачевского. Вопрос - как долго будут спорить два таких архитектора?
В бухучете, как и в любом, нормативно оформленном процессе, такая платформа есть. Поэтому споры бывают, но очень недолгие и очень предметные. А вот о чем сейчас спорят "архитекторы"? О том, у чего никаких научных или нормативных платформ - нет! Поэтому споры очень общие, малопредметные и очень долгие. При этом все аргументы сводятся к формулировкам "а я так думаю", "мне так больше нравится" и т.п. ("я - художник, я так вижу!"). Критерии истины равняются аргументам - "Так будет правильно потому, что мне так нравится!".
И озабоченный хлопотливый РП бегает и пытается унять эти споры. Очень продуктивно! Надеюсь, заказчик за все это заплатит))
Применительно к Вашему же тексту, я продолжаю - сначала Ломоносов создал (условно) "Электромагнетизм" (так-то, его создали другие товарисчи) и только потом появились электрики в ЖЭКах. А у некоторых программистов другая очередность, они в виртуале пытаются создать то, чего в реале еще никто логично не описал, в научных диспутах и практических опытах это не отстоял и не подтвердил! Я же про это писал. Виноват, если не довел свою мысль понятнее!
Что касается сущностей. А сущности тоже живут в каких-то ареалах обитания. Лучше всего они чувствуют себя на прочных, проверенных временем, нормативных платформах. Попытка создать сущность вне платформы моментально превращает такую сущность в бездомное привидение, которое колыхается вечно где-то "между" и везде является лишним. Найдете на платформе пустое место - создайте там свою новую сущность и проследите, чтобы ее соседи не взбунтовались - и пусть живет, если она кому-то нужна. Бухгалтер берет кусочек своей бухгалтерской платформы, эдакое общежитие под названием "План счетов", и помещает туда новую сущность в виде нового счета. И никто не против, ибо вновь созданная сущность начала жить рядом с себе подобными. Конечно можно и лимузин в курятник разместить - мир не рухнет, но куры пропахнут бензином, а лимузин вечно будет засран....
user596529_a-ivashenko60; Andreev.a; +2 Ответить
27. user596529_a-ivashenko60 27.01.23 10:47 Сейчас в теме
(21) Комментарии Дмитрия (их несколько и этот заключительный) являются отдельной самостоятельной сущностью. Сущностью отдельной от комментируемой статьи. Обобщающей, подводящей определенный итог теме затронутой в статье. Можно статью не читать, прочитать лишь указанные комментарии. Сами по себе комментарии (как новая сущность) тянут на хорошую статью с важной для сообщества программистов (аналитиков, архитекторов ...) темы. Дмитрий, предлагаю вам на базе здесь написанного создать статью. Плюсую!
MariaTemchina; +1 Ответить
28. DemetrKlim 157 27.01.23 13:17 Сейчас в теме
(27)Спасибо! Даже если это очень тонкий красивый тролинг - он красив!) Человек, пишущий красивые тексты, обычно пишет такие же красивые коды)
Я пробовал писать статьи, но свист был очень громкий, а прилетающие тапки были тяжелые и плохо пахли. Я прекратил написание статей. Иногда просто не сдерживаюсь и что-то "отпостирую". Но читатели все-равно плохо реагируют(
Оставьте свое сообщение