Морковка спереди, морковка сзади

Про исуп часть 2. Что не так с проектными системами и почему серебряной пули нет? Для начала надо прикинуть, какие процессы управления минимально должны быть оцифрованы. Тут все зависит от размера команды. К примеру, я знаю команды по 10 человек, которые работают вообще без систем, и им нормально. По моему опыту, необходимость планирования, учета и контроля возникает на границе 20-30 человек. Минимальный гигиенический набор процессов под оцифровку: •  управление проектом •  управление ресурсами •  управление задачами •  управление бюджетом •  управление коммуникациями Нет, тут нет управления рисками и других процессов, и это осознанно: я пишу именно о необходимом минимуме, после которого можно переходить к рюшам типа рисков или портфолио менеджмента. А теперь давайте поглядим, а есть ли системы, которые пытаются все это вместить? Да, есть. И я даже работал с некоторыми или ковырялся в них. Они или неудобны для всех процессов (пример Б24, который, как bpm движок, портал и crm я очень уважаю, но управление проектами и тем более встроенный месседжер – простите, ребят), или откровенно дороги (привет, Wrike в редакции для бизнеса без кучи фич по 25 баксов за юзера за мес и в облаке). Итого: или дорого, или в облаке, или неудобно. Или все это комплектом вместе. И даже если такая чудо-юдо-система найдется (расскажите, если вы такую видели, вдруг я пропустил), на пути у нее встанет стеной Легаси. И не такое уж плохое Легаси. JIRA, скажем. А Джиру попробуй замени – все зубы обломаешь. Потому что воспроизвести ее бизнес-процессы и чудесный JQL пока что удалось только Ютреку (из тех что я видел). А уж заменить дашборды и плагины Джиры вообще невозможно – это отдельный огромный рынок софта. Даже самые резвые заменители Джиры на российском рынке прямо сейчас сильно вянут, если спросить «а что у вас с плагинами?» 😁😁😁 Чудо системы нет, а даже если и есть, главная сложность – полный переход всей команды на новый софт и неизбежные проблемы из-за этого. Кто-то скажет: «бро, ты же сам склоняешь везде JIRA, отличная система, особенно если добавить пару плагинов – почти идеал». Так, да не так. Во-первых сама по себе JIRA – это таск трекер, но не ИСУП, во-вторых даже с плагинами типа Structure или Big Picture она не закрывает все процессы. Какой выход? Я считаю, что выход - использовать то, что есть в вашей компании, объединяя его в единое информационное поле, добавляя недостающие кубики и дополняя то, что уже есть и работает. Вопрос коммуникаций подавляющее большинство решает корпоративным мессенджером или Телегой. И менять его ради вашей ИСУП, в которую встроен мессенджер, никто не станет. Да и нафиг надо, достаточно просто сделать платформу с коннекторами к вашему мессенджеру. Таск-трекеры не переплюнуть по функционалу управления потоком задач никогда и никому, они идеальны для этого. Так зачем отказываться, тем более что они у всех уже есть, и работа в них более-менее отлажена? С самими ИСУП веселее. Их великое множество, но я среди них не видел ни одной, качественно интегрированной с трекерами, чтобы это давало возможность проводить план/фактный анализ онлайн и уж тем более – с мессенджерами, чтобы использовать чатботы. Да, Гантт есть у всех, бюджет считать они могут, но на основании чего – табелей, которые все заполняют «от балды»? Я считаю, это прошлый век. Поэтому я считаю, что на рынке есть потребность в ИСУП, которая сможет объединить таск-трекер, мессенджер и проектную систему в единое пространство, обеспечивая сведения по проектам, ресурсам и эффективности он-лайн, секунда в секунду. И, если UI в этой системе будет не такой лохматый, как в MS Project, и будет решение on premise, так как заказчики в РФ ревниво относятся к чувствительным данным (а ставки и бюджеты - фининформация) - это будет убийца всех остальных систем. Если вы такие системы знаете - расскажите. Я не знаю ни одной такой.

Сегодня ночью мне снилось как мы всем проектным офисом выбираем проектную систему.😁 Вот что значит, писать по вечерам программные статьи. А пока статья о выборе проектной системы пишется, предлагаю почитать небольшое исследование https://habr.com/ru/news/861568/ В каментах непременный для Хабра (все таки программистский ресурс) срач на тему методики подсчета - к ней правда есть вопросики. Но все сходятся на том, что одна из задач менеджмента - это видеть таких "призраков" и заниматься ими. Я с этим тоже категорически согласен. Первым бездельника все равно видит или его прямой функциональный руководитель или прямой линейный. А если не видит - вопросы к менеджеру у меня будут 100%. Но есть и еще важный момент. В идеале, в оцифрованном мире, это должна показывать сама система. Предлагаю желающим подумать, а как этого достичь?

и пару слов о делегировании))

Подбивая часть 1: по моему мнению, сейчас на рынке качество управления ИТ командами в smb (small-to-medium business) находится на низком уровне. Есть немаленькое подозрение, что и в крупняке несильно лучше, там еще тот зоопарк. И это низкое качество будет падать: в отрасль приходит очень много новичков, которые не понимают, как можно делать правильно. Зато каждый у нас в АйТи мнит себя дофига умным и именно он «знает, как надо». Итог я вижу вокруг себя: начинается все от некачественных постановок в тикетах, продолжается некачественными планами, а кончается совершенно непрозрачной работой всей ИТ команды, которая неясно что делает, все время двигает сроки вправо и всем кругом ноет, что ей должны. Причин две: - непонимание того, что если вы автоматизируете всех вокруг, стоит немного подумать и про себя, и потребовать на свой отдел небольшие деньги на автоматизацию (запросить 1-2 млн/год бюджета на ИСУП при том что ваш отдел экономит десятки миллионов не должно быть проблемой). - Надежда найти волшебную таблетку в виде единой ИСУП, которая закроет все потребности. История в том, что такой таблетки не существует. Нет такой одной системы, которая качественно закрывает все потребности ИТ команды. Но об этом – в следующей части. А согласных или несогласных приглашаю резвиться в каментах))

Про ИСУП: кто где работает и где работать лучше и правильнее? Часть 1 В чате всплыл вопрос о проектных системах, они же ИСУП. Выскажусь по этому поводу, тем более опыта вполне достаточно: за 25 лет я много, где поработал сам, а за пару лет управленческого консалтинга и развития нашего собственного продукта я посмотрел, как и на чем сидят другие компании. Да, офтопиком скажу, что я развиваю в партнерке с уважаемыми ребятами собственный продукт управления ИТ командой, который должен быть лишен основных болячек, которые я перечислю ниже. Если интересно, я про это расскажу отдельно. 1. Кто на чем работает и какие с этим проблемы: - На первом месте куча самописных решений в стиле «дешево, но сердито». Обычно берут что-то опенсорсное и допиливают своими силами до своего понимания, что потом и зовется «Проектная система». Часто это Redmine. Самописное что-то обычно автоматизирует процесс заведения задач и их контроля. Короче, выполняет роль трекера. Реже пилится собственный Гантт. До планирования ресурсов, обычно, не доходит никто. - На втором месте старая добрая JIRA, которой пользуется подавляющее большинство. Никуда она особо не ушла, люди работают на локальных копиях, все хорошо. Ну как хорошо, команды сталкиваются с проблемами, о которых я напишу ниже. Связаны они с тем, что JIRA – это часть ИСУП, но далеко не вся ИСУП. - На третьем месте раньше, по моим данным, был 1С. То с чем сталкиваюсь лично я – это не 1С, а Битрикс 24. Сама по себе очень неплохая система (последние 5 лет мы ее неплохо внедряли) для целей автоматизации предприятия, но имеющая недостаток любой системы, которая попыталась впихнуть в себя вообще все. В части управления именно ИТ командами, у меня к Б24 есть большие претензии (Гантт слабый, бюджетирования нет, а процесс работы с досками и задачами несравнимо хуже стандарта, который задает JIRA) 2. С какими трудностями сталкиваются ИТ команды на сегодня? ИТ команда состоит из многих участников и боли у каждого свои. Проедусь по всем: - исполнители: плохо планируется работа, узнают о задачах в последний момент, огромный вал внеплановых задач, попытка сделать всем хорошо на 64 часа, когда в неделе всего 40, выгорание – увольнение «да манал я ваш блядский цирк» - руководители проектов: у этих чаще «все хорошо» в стиле мема «it’s ok». Менеджер – штука неприхотливая: он привык работать с тем что ему дали и часто не понимает, как правильно. Обычно РП примерно представляет, кто у него чем занимается, но, если приглядеться, у них таже проблема, что у исполнителей: непрозрачные планы, они перегружены, но показать, где, они не могут и мучаются от перегруза. - СТО/CIO/РПО: вал внеплановых задач от бизнеса, которому невозможно сказать: «НЕТ, или дайте больше ресурсов», потому что у вас нет никакого обоснования в виде учетной системы. Много времени уходит на отчетку, которой бизнес недоволен ("почему твои айтишники жрут такой огромный ФОТ, а работают так медленно?!"). Сам CTO/CIO/РПО обычно примерно понимает, кто чем занимается, но в деталях разобраться без своих лидов не в состоянии. Ну и я уже молчу об измерении эффективности внедрения продуктов/проектов/фичей с целью понять ROI Для бизнеса. Такое делают откровенно единицы на рынке. - CEO: вообще часто не понимает, чем занимаются его айтишники. Я говорил со многими СЕО. До 20-25 человек в ИТ команде обычно есть понимание и без ИСУП, у кого какие задачи. А потом у СЕО неизбежно встает главный вопрос: «я плачу этим ребятам чудовищный ФОТ, по 400 на нос (с накладными), а почему они ничего не делают? Больше того, они мне очень убедительно за мои же бабки рассказывают, что козел тут я?!

Так. Из-за большой загрузки на этой неделе пара умных статей отменяется (надо пару систем вывести в продакшен 🔨, а это требует времени). Зато у меня для вас есть песня. Мне кажется все уже слышали, но: а) мало ли кто не в курсе - тогда слушайте best practices отрасли и учитесь 😁 б) те кто в курсе - не забываем, работаем 😁 https://music.yandex.ru/album/5827420

Мотивационное на начало недели. Так получилось, что вас окружают дебилы. Сотрудники не понимают, что от них нужно, хотя это должно быть очевидно даже без объяснений и напоминаний. Заказчик – просто конченный: не понимает очевидных вещей, бухтит на ровном месте и вообще – вместо того, чтобы накинуть бюджета, как ему сказали, ходит и че-то там эскалирует про плохого менеджера на стороне исполнителя. Ваш линейный руководитель, вместо того чтобы утешить и поддержать вас, тоже встает на сторону заказчика. Руководство вашей компании тянет ее непойми куда, и создается ощущение, что ваша «компания, как курица без головы: бегает, машет лапами, суетится, но бегать остается недолго» (реальная цитата одного недовольного, кстати). Короче: вы один в кольце дураков, и вас никто не понимает. Бывало что-то подобное? Тогда поздравляю, вы – ленивая и эгоистичная задница. Почему? Первое. За свой 25+ летний опыт в разработке ПО я не видел тупых руководителей и заказчиков. Вообще. Я работал с совершенно разными людьми: аналитиками и министрами, складскими работниками и вице-губернаторами. Тупых и дебилов там не было. Ни одного, ребят. Вообще. Конечно, может быть мне везло, а вам не везет, но вероятность небольшая. Да, были те, что не понимали, кто ошибался (все ошибаются), но тупых не было. Второе. Если человек не тупой, а я думаю, что он тупой, то кто реально в этой паре дурак? Поглядите в зеркало. И скажите себе: это не заказчик тупой, это я – ленивая жопа, которая не способна понять мотивацию другого человека и договориться. Третье. Психологическое. Все эти мысли в виде: «они козлы, а я няшка», это: а) детская эгоистическая позиция «не хочу никого понимать, хочу чтобы поняли меня»; б) попытка самоутверждения за счет другого; в) банальное неуважение к другому человеку. Любой из трех пунктов лишает вас возможности услышать другого человека, а все вместе – дают гарантию, что вы его не услышите. Итогом – вы самоутверждаетесь успешно, но профита в деньгах это не дает. Четвертое и последнее. Чтобы понять мотивацию другого, надо говорить ртом и принимать его ответ серьезно. Спрашивать вопрос и слышать ответ. Если вам кажется, что ваш заказчик отвечает дикую дичь, объясняйтесь дальше. Ваш заказчик не дурак, он вас способен понять. И если понять не может – тут как минимум 50% ваших, это вы плохо объяснили и не можете донести мысль. Вкратце так. Если вам не нравится подход заказчика или вашего руководства – пойдите и поговорите. Решение любой проблемы начинается с разговора. Если все у вас козлы, а вы даже не попробовали поговорить, то козел - вы. Если вы поговорили, вас не услышали, вас это бесит, а вы продолжаете работать и страдать, то козел – тоже вы, потому что не можете поднять попу и сменить работу на ту, где вас услышат. Если вы знаете, что вас не услышат нигде, мир несовершенен, и кругом козлы – перечитайте статью еще раз и далее страдайте молча: вы неисправимый козел. Весь мир договаривается, один вы в белом. Ну, просто не мешайте работать, отойдите в сторону и страдайте молча. Бонусом: сказанное выше касается любых отношений. Если вам кажется, что ваш партнер козел, а вы няшка в белом – вам кажется. Всегда есть место работе над собой. Сказанное выше не отменяет наличие своего мнения. Услышать другого != сделать так, как он хочет. Тут надо искать мой любимый баланс: важно слышать то, что говорят другое, но также важно не забывать про ваше мнение в рамках вашей компетенции. ⚖️ До нового года еще 5 недель, дедлайны горят и планы краснеют ) Желаю всем успеть начатое. Ну, или не успеть и получить бесценный опыт факапа))

Тут в комментариях разгорелся нешуточный холивар на тему "списывать время или нет?" Вопрос и правда очень интересный, давно хочу про него написать на Хабре, но он требует нешуточной подготовки. Поэтому статью обещаю к новому году, но это не точно 😁😁😁 А пока статья не пишется, я расскажу историю. Делал я как-то большой проект и был у меня там аналитик. Он был возрастной, лет под 60, дофига опытный. Работал до этого в госорганах руководителем, как раз по профилю нашего проекта. И умел он писать офигительные ТЗ. Он писал их как из пулемета, с первого прохода, отлично раскладывая все функции. Но писал он только 2-3 часа в день. Это было видно внешне: вот он сидит на расслабоне и пинает балду, а ближе к вечеру подбирается, садится и долбит по клаве, как заведенный. И не было ни разу, чтобы он не успел в срок. И меня, как РП, это всегда устраивало. Я понимал, что он дает запас, хороший запас. Но при этом запас меня вполне устраивал про срокам и по бюджету, а я знал, что если случится факап, он всегда пойдет мне на встречу и сделает быстрее, не устраивая истерик, потому что сейчас на встречу иду я. Мораль: С одной стороны, формализовывать договоренности важно и необходимо. Контролировать их исполнение - тоже. С другой стороны, отношения в команде это всегда обмен. Сегодня я иду на встречу тебе, а завтра ты - мне. Как только я решаю полностью формализовать вопрос отношений в команде, я получаю формалистику и бюрократию вместо реальной работы. И команда здесь - понятие самое широкое: - вы идете на встречу разработчику, отпуская пораньше, а он потом вас прикроет, выйдя поработать ночью, хотя не должен. - вы идете на встречу вашему заказчику, реализуя небольшие доптребования, а заказчик потом вспомнит, что вы нормальные ребята позовет вас на следующий проект, где вы хорошо заработаете. - вы героически спасаете вашу компанию, работая в режиме нереальных сроков, а компания взамен... 😁 Ладно, нормальная компания это тоже должна ценить, видеть и "затыкать рот баблом", как говаривал один мой коллега, когда его выгоняли на работу в очередные выходные 😂😂 В любых отношениях должен быть обмен. Если вы только требуете - с вами не будут хотеть работать Если вы только отдаете - на вас будут ездить Мораль, которую я так люблю: везде должен быть баланс. Так что следите за балансом. ⚖️

Вчера наткнулся на вакансию Администратора проектов одной немаленькой ИТ-компании (лично не знаю, не работал, но, судя по открытым данным, несколько сот человек работает). Читаю: "требуется собирать таймшиты со списаниями времени по отделам и делать сводные отчеты...." и выпадаю в осадок. На дворе стоит 2024, блин, год. Илон Макс пуляется ракетами в космос. MS project со своими таймшитами уже устарел 10 лет назад, а народ списывает время по отделам в Эксель?! Cерьезно!?! Иногда я в шоке от того, как мои собраться айтишники, автоматизирующие крупные компании, серьезнейшие процессы, сервисы с миллионами пользователей, алготрейдинг (не путать с "алко" 🤣) не могут автоматизировать процесс управления самими собой. Чтобы было прозрачно от каждого таска, и до ROI на фичу/проект/продукт. E2E процесс управления ИТ командой я видел в единицах компаний, обычно все строится на "Позовите Васю, Вася скажет" или на собирании нескольких экселей в единый сводный. Выглядит как в психологии: психолог не может проработать сам себя, ему для этого нужен другой психолог. Так и Айтишник, кажется, не способен автотматизировать сам себя, ему нужен второй айтишник 😁 Ну а к вам небольшой опрос щас будет.