TLDR:
Антиманифест методологии разработки ПО
Процесс это не продукт
Руководство, а не менеджмент
Диалог, а не диктат
Вот и всё, остальное вы можете додумать сами, но если хотите, продолжайте чтение.
Процесс это не продукт
За свою (очень) долгую карьеру в технологической сфере я ощутил на себе большинство методологий разработки ПО, и этот опыт показал мне, что они больше похожи на обязанность, а не на помощь. Скажу больше: мне кажется, что избыток методологии гораздо опаснее её недостатка. Однако культ Одной Истинной Методологии продолжает процветать, и стоит поразмыслить над тем, почему так происходит.
Если встретишь Будду на дороге убей его!
Думаю, что одна из причин заключается в том, что многие/большинство/все из нас втайне подозревают, что мы делаем всё не так, и есть кто-то, делающий всё правильно; если мы последуем его совету, то тоже будем делать правильно, и все ошибочные оценки, баги, плохой код и т.д, и т.п, исчезнут.
Не нужно так думать, они никуда не денутся.
Ещё одна причина это экономика методологии разработки ПО. Она похожа на чудесную рекламу об инвестициях. Люди, продающие обучающие курсы, книги и другие атрибуты, действительно хорошо зарабатывают. Но они зарабатывают на курсах, книгах и так далее. Если бы они были хороши в своевременной разработке ПО без багов, то зарабатывали бы намного больше. Но они, как и консультанты по инвестициям, зарабатывают на нашей технологической неуверенности.
Если можешь делать, то делай. Если не можешь, то управляй.
Однако ещё одна причина это бесконечное разрастание менеджмента среднего звена, поражающее и крупные, и мелкие компании. Если компания растёт, то нам кажется, что ей нужно больше менеджмента. И ещё. И ещё. Почему? Каков карьерный путь менеджера? Он нанимает менеджмент более низкого звена. Хуже того компании поддаются этому, они склонны укреплять свою иммунную систему. Любые попытки изменения статуса-кво менеджмента будут угрозой самим основам культуры менеджмента. Не говоря уже обо всех этих должностях в менеджменте. Нужны инновации? Отлично. Давайте наймём руководителя отдела инноваций. И, разумеется, менеджменту обязательно нужно чем-то заниматься, и это процесс, отслеживание спринтов, доски trello, что угодно, чтобы заполнить восемь рабочих часов.
Руководство, а не менеджмент
И это приводит нас к следующему пункту манифеста: к лидерству. Знаете, такому настоящему руководству. Ты приходишь и показываешь путь вперёд. Лично каждому, чётко, по одному программисту за раз, и не только то, что они должны знать, но и спринты с use cases. Нужно иметь достаточно технических возможностей, чтобы обучать, готовить и мотивировать. И учиться самому. Сообщать всем, вплоть до уборщиков, куда и зачем мы движемся. Не один раз, а постоянно. Организации, которые будут это делать, окажутся самоуправляемыми. Почему? Потому что люди (даже программисты) умны. Если даёшь им информацию и полномочия, они думают, правильно расставляют приоритеты, не ругаются из-за смены целей и не особо нуждаются в менеджменте. Если сделать всё правильно, то окажется, что вы следуете за коллективом, а не ведёте вперёд, потому что культура команды становится больше, чем любой из её участников.
Диалог, а не диктат
Наконец, мы добрались до последнего пункта, который следует из предыдущего. Коммуникации никогда не должны быть односторонними. Информация должна распространяться и вниз, и вверх. Единственный смертный грех не неудача, а нежелание коммуникации. Если обращаться с людьми правильно, они умны, и с большой вероятностью у них есть более качественные идеи, чем у руководства. Каждый должен быть выслушан с уважением.
Если всё это заставило вас ощутить неудобство, то это хорошо. Для того и написана эта статья.
P.S.: Никакой Jira.
На правах рекламы
Многие клиенты уже оценили преимущества серверов от Вдсины.
Мы предлагаем выделенные и виртуальные серверы. Максимальная конфигурация позволит реализовать практически любую идею 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Закажите и вы!
Подписывайтесь на наш чат в Telegram.
