проект | Владимир Бычко об управлении проектами

Владимир Бычко об управлении проектами

пиэм разъясняет, предостерегает, рекомендует

Тег: проект

5 типов руководителей проектов, раздражающих сотрудников

Изображение с unsplash.com

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

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

Душнила

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

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

В целом, я считаю, что душнила ошибся с профессией и он намного комфортнее чувствовал бы себя в роли QA.

Демонизатор

У этого всегда одна и та же пластинка. Заказчик-дурак тычет мышкой в картиночки гордо и опять требует сделать херню. Хлопает дверью, крутит пальцем у виска, строит замки из песка. Ну что я могу сделать, давайте подчинимся, запилим, что требует, чтобы отстал.

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

Как уживаться с демонизатором? Ваше оружие — слово «зачем» и «чтобы что», сказанные достаточное количество раз.

«Терапевт» — всё знает, но ничего не умеет

Такой менеджер отлично умеет проходить собеседования. Отобъёт любой теоретический вопрос. Рубит во всех методологиях, в том числе экзотических. Всегда может рассказать, какие планы на проекте, всякие нюансы. Но на практике работа у него не движется. Вроде, команда чем-то занята, всё время что-то пилит, но сроки сдачи постоянно переносятся, результатов нет.

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

Руководители такого типа обожают критиковать коллег за недостаточную теоретическую подкованность и вообще, козлить.

Бороться с ним необязательно, его всё равно, уволят за низкий перформинг рано или поздно. Что делать, если вы «терапевт»? Идти в консультанты, там вы сможете развернуться со своим теоретизированием на полную. Или приобретать с потом и кровью реальный управленческий опыт.

«Хирург» — всё умеет, но ничего не знает

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

Такой руководитель, как правило, берётся за дело с жаром, но постоянно сталкивается с тем, что чего-то попросту не знает. Что в план нужно закладывать время на юнит тесты и автотесты, что нужно организовывать механизм управления изменениями, которые будут меняться после каждого демо заказчику. Что программисты совершенно невзаимозаменяемы, что два мидла, нанятые взамен уволившемуся сениору, не тянут сениорский объём работы. Ну и другая айтишная пепяка.

На самом деле, «хирург» небезнадёжен, если способен учиться. Помогите ему подсказками и дело пойдёт веселее.

Передаст

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

Зато обожает отчитываться перед руководством, присваивая чужие заслуги. Типа, всё это сделано только при помощи моей твёрдой менеджерской руки. Иногда выезжает на былых заслугах, иногда является другом или родственником кого-то из руководства, в любом случае, избавиться от него может быть затруднительно.

Как бороться? Научиться говорить «нет», когда вам сваливают непрофильные задачи. Ну и добиться того, чтобы вас включили в нужные чаты и общаться умными программёрскими словами с другими программёрами лично.

Мысли из Линкадина — 17

Изображение с pixabay.com

О ценности высказываний

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

© «В Бореньке чего-то нет».

* * *

О законе Дерека Прайса

Если вам частенько кажется, что вы работаете больше всех и тянете на себе весь проект, есть вероятность, что вам не кажется. Есть закон Дерека Прайса, согласно которому 50 % работы в любом проекте выполняет число людей, равное квадратному корню от численности команды.

То есть, если в команде 9 человек, 50 % работы выполняют трое. Это ещё одно применение квадратного корня в проектном управлении.

* * *

Об ущербности слова «надо»

Конечно же, самое плохое слово в бизнесе и жизни — «один». А на втором месте слово «надо». Если начать разбираться, можно прийти к выводу, что на самом деле, давно уже никому не «надо» или надо, но не так, как привыкли, потому что среда изменилась.

* * *

О предновогодних неделях

Существует такая идея, что за пару-тройку недель до НГ в бизнесе начинает властвовать фраза: «Давайте уже после праздников». У меня же на деле, каждый раз предновогодние недели бывают просто адовыми. Даже если не нужно ничего сдавать заказчику, вечно нарисовывается большой объём задач, которые нужно кровь из носу решить до НГ.

Даже по временам офисной работы помню, как в последний день перед каникулами добивал отчётность и покидал офис в половине десятого вечера.

В общем, у меня почему-то бывает: «Давайте закончим это до праздников». Ну, тем приятнее потом отключиться на неделю от всей этой движухи.

* * *

О неудобности логичного

Логичное не всегда удобно, удобное не всегда логично. В квартире родителей раздельный санузел, справа ванная, слева туалет. Выключатель света находится слева от туалета, кнопка ванной справа, кнопка туалета слева. Вроде, логично.

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

Без исследований, хорошего юзабилити добиться сложно.

* * *

Про обнимание словами

Я снова про «обнимание словами». Вам ничего не будет стоить добавить к дате слово «включительно», а адресату сообщений это сэкономит массу времени.

Итак:

Документы принимаются до 9 января — плохо.
Документы принимаются до 8 января включительно — нормально.
Последний день подачи документов: 8 января — тоже нормально.

* * *

О важности повестки

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

* * *

О кожаных салонах

А вот ещё как бывает. Компания заказывает в приличной веб-студии корпоративный сайт. Студия его целиком дизайнит, верстает, кодит. Получается офигительно. Но поддержку компания заказывать не хочет, считает, что справится с обновлением информации на сайте самостоятельно.

И постепенно к офигительному «студийному» контенту добавляется собственный, с орфографическими ошибками, знаками дюйма вместо кавычек, минусами вместо тире, пробелами перед знаками препинания и ужасными фотографиями. Компании кажется, что это всё норм, никто не не обращает внимания, но на деле сайт выглядит как дорогой кожаный салон, который в некоторых местах прожжён сигаретами. Да, он от этих сигаретных ожогов не перестаёт быть дорогим и качественным, но дырки привлекают внимание и портят впечатление.

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

* * *

Об одном правиле

В моём любимом сериале «Как я встретил вашу маму» Барни всё время говорил, что у него есть только одно правило и изрекал какую-нибудь странную мудрость (например, что не стоит морочить голову девахе, у которой фамилия заканчивается на гласную, у неё точно есть братья). Но прикол в том, что мудрость была каждый раз разная и правил у него было огромное количество.

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

* * *

О перегреве твиттера

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

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

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

* * *

О возрасте

В неполные десять: Бегаешь по стройкам, прыгаешь с крыш гаражей, падаешь с велосипеда, получаешь люлей от старшаков и всё нормально.

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

* * *

Об авторизации

Как бы я улучшил все сервисы и приложения. Добавил бы в форму авторизации флаг: «Это мой личный ноут, за которым я 99 % времени работаю дома, где больше никого нет, не разлогинивайте меня, пожалуйста, вообще, никогда».

* * *

О лошадях и проектах

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

С проектами такая же история, им свойственно постоянно фоново менять параметры, чаще всего, в сторону расползания бюджета. Не забывайте подтягивать седло, чтобы не съехать.

* * *

О редких инструментах

Большинство специалистов стараются придерживаться принципа 80/20, изучая только самые нужные инструменты и методологии. Но настоящего профессионала отличает умение в той самой единственной ситуации, когда нужен редкий инструмент, умело применить именно его.

В 2009 году. Барселона играла против Эстудиантоса. В овертайме, на 110 минуте Алвес навесил справа на Месси, а тот за мгновение принял решение, забив гол не головой, не ногами, а грудью в падении.

В 2008 году МЮ играл против Вест Хэма. Криштиану Роналду получил не самый качественный навес справа, мяч пролетел мимо защитников. Бить ногами было неудобно, слишком высоко. Головой тоже не ударить, слишком низко. И Криш забил… пахом.

Изучайте редкие инструменты, в общем.

* * *

О секрете входа в доверие

Проявляйте искренний интерес. Это самый лучший метод установления хороших отношений, как в личной жизни, так и в работе.

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

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

Проявлять интерес — это настоящий золотой ключик к людям.

* * *

Об усложнениях

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

Может показаться, что автоматизированная подготовка отчёта затратная. Допустим, сто, двести часов. Сделаем пока ручное формирование отчёта. Я вам гарантирую, что истинные затраты быстро перевалят за тысячу из-за непониманий плохо написанной инструкции, ошибок при оформлении, банальных забывашек, необходимости пинговать.

У вас должна быть очень веская причина требовать ручное составление какого-либо отчёта. Ну и эту причину было бы неплохо подчинённым пиэмам озвучить.

* * *

О затачивании пилы

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

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

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

Мгновения сливаются в года, мгновения прессуются в столетия. Точите пилу.

* * *

О дарк-паттернах в менеджменте

Обычно менеджеры стараются мотивировать сотрудников, способствовать их росту и развитию, чтобы они приносили больше пользы компании, в общем, работать в условный «плюс». Но однажды я столкнулся с обратным приёмом, работе «в минус».

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

И руководитель раз в пару недель вызывал меня в коридор и начинал сверлить мозг. Медленно работаешь, мало задаёшь вопросов, мало проявляешь инициативу. В отличие, например, от коллеги Ольги, у неё вот всё отлично получается.

Закончилась эта сверлёжка тем, что перед завершением испытательного срока он снова меня вызвал и сказал, что я либо соглашаюсь на добровольный даунгрейд на одну категорию (со снижением зарплаты), либо компанию покидаю. Удалёнка тогда была мало распространена и найти работу в своём городе было непросто, я согласился на даунгрейд.

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

Я ни в коем случае не призываю применять такой подход, но должен признать его определённые плюсы. Внушить двум сотрудникам, что они неполноценны и сэкономить на их зарплатах, получая тот же объём работы — это тоже менеджмент, пусть и со «знаком минус».

* * *

О словах

Если заглянуть в словарь Даля, можно обнаружить, что большинство слов оттуда нам уже незнакомы.

Пипка, пипица. Это курительная трубка, а не то, что вы подумали.

Хухря. Так говорили про растрёпанных, нечёсаных замарашек.

Ендовончик. Любитель пива и всяческих попоек.

Потиральце, потирушка. Это… полотенце. Что-то, чем можно вытереться.

Юзилище. Тюрьма. Хотя казалось бы…

Шепотник. Сейчас начнутся шутки про шептунов, но так называли ябедников и клеветников.

Мужатица. Так говорили про замужних женщин. По-моему, всё логично.

Козлодёр. А это про «певцов» с очень плохим, сиплым голосом. Как у козлов.

А ведь через какие-то сто-сто пятьдесят лет наши симпы, краши, альтушки с Госуслуг и скуфы будут выглядеть так же странно и устаревше.

* * *

О встречах с ранья

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

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

* * *

О согласованиях

Несколько раз за карьеру я слышал: «Твой проект — это как маленький бизнес, в котором ты владелец. Делай всё, что хочешь, главное, оставайся в пределах треугольника». Особенно комично это звучит в компаниях, в которых каждое значимое проектное действие нужно согласовывать с десятком начальников и сопровождать заполнением нескольких хитрых отчётов.

* * *

О фидбеке

Давно не было опросов. В этот раз о тонком вопросе баланса информированности руководителя и нормальной атмосферы в коллективе.

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

А как быть с неофициальной информацией? Видятся два варианта.

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

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

Итак, ваш выбор?

* * *

Об электронных письмах

Электронное письмо хочется заполнять в том, порядке, в котором идут поля. Кому, Копия, Тема, От Кого, само письмо. Но нет ничего хуже, чем отправить недописанное письмо, особенно большой группе адресатов.

Лучше писать в обратном порядке, сначала само письмо, потом тема и только потом адресатов, так вы себя застрахуете от подобного конфуза. В целом, мысль не новая и многократно озвученная, но мне хотелось бы закрепить её у себя.

* * *

Об оптимальном размере ФОТ

Конечно же, хочется платить сотрудникам побольше. И нанимать крутых высокооплачиваемых специалистов. Но практика показывает, что при размере ФОТ больше 50 % от маржи, компания не сможет развиваться, не хватит денег на продвижение, оснащение рабочих мест и другие важные вещи. Идеальный размер ФОТ — 30 % от маржи.

* * *

О маркетинговых паттернах

Если бы маркетологи сделали калькулятор:

* * *

Об испытаниях

Преподаватель: Что бы спросить у него, чтобы он точно ответил, я пошёл на компромисс с совестью и поставил ему «уд»?
Студент: Во валит…

Вовремя и в рамках бюджета

Изображение с unsplash.com

Вовремя и в рамках бюджета. А так вообще, бывает? У меня было ровно один раз. Руководство попросило сделать индивидуальную доработку (кастомный отчёт на Microsoft Reporting Service) прям образцово, чтобы можно было показывать коллегам как пример. Отчего же не сделать? Какими принципами я руководствовался, чтобы это сделать? Какие ходы провёл?

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

Артемий Лебедев, дизайнер.

Артемий Лебедев

Ководство, § 178

Менеджер давно в компании. Я тогда работал третий год и детально разбирался, к кому с каким вопросом идти. Это прям основа, без этого ничего не выйдет.

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

Только после того, как заказчик принял первичную оценку и сказал «делаем», приступил к точной оценке. Или фазе планирования. Оценивают те, кто будут делать. Я сам выступаю в роли аналитика, разработчиком будет опытный чувак, который ранее делал такие вещи. Он же делал первичную.

Сбор требований. Созваниваюсь с заказчиком, выясняю бизнес-проблему, чего он хочет добиться этим отчётом, почему именно на RS. Разбираемся с входными параметрами, показателями, агрегацией итогов.

Прототипирование. Открываю Excel и прям рисую отчёт, максимально приближённый к реальности. Показываю разработчику, он указывает на вещи, которые будет невозможно или трудно реализовать. Ещё несколько раундов созвонов, расспрашиваю разные детали про отчёт.

Написание ТЗ. Максимально аккуратно, «сверху вниз» фиксирую всё собранное в ТЗ. Согласую ТЗ с заказчиком. Увидев ТЗ они добавляют ещё хотелок. Обсуждаю их с разработчиком, вношу в ТЗ. Это был самый длительный этап. Из-за того, что заказчик не спешил, мы созванивались пару раз в неделю по часу-полтора и не спеша формировали ТЗ. Этап вышел месяца полтора.

Точная оценка. Вместе с разработчиком пилим ТЗ на таски, оцениваем эти таски. Получаем чистую оценку разработки. Применяю корпоративные «волшебные формулы», по которым рассчитываю оценку тестирования, накидываю другие накладные затраты. Накидываю время, которое ранее потратил на прототипирование, требования и ТЗ.

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

Формирую итоговое ТЗ и точную оценку, засылаю заказчику. И только после того, как заказчик мне отвечает на имейл, что согласен, мы рассчитываем сроки с учётом реальной загрузки разработчика.

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

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

Паровоз паззл.

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

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

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

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

Пока журавли говорят, синицы делают.

Мысли из Линкадина — 13

Изображение с unsplash.com, автор Dawid Zawiła

Сценка в лицах: «Как работает страховая»

Страховая: Эй, клиент, купи у меня страховку, а когда у тебя случится беда, я помогу деньгами.
Клиент: Хорошо, вот деньги.

Клиент: Эй, страховая, у меня случилась беда, теперь ты мне поможешь?
Страховая: Нет :3

* * *

Об исторической спирали и сайтах знакомств

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

Поэтому придумали сервисы, в которых нужно было лайкать и в которых писать можно было только после взаимных лайков. И вот, на этих сервисах некоторые девушки стали писать «не вижу лайков, пишите сразу в телеграм/инстаграм». Часть из них мошенницы, но остальные жаждут очередного поворота спирали.

* * *

Хорошая вакансия

Develonica (аутсорс-разработка, центр экспертизы ГК Softline, офисы в 5 городах, 1500 сотрудников) ищет scala-разработчика на проект, связанный с ЭДО, для государственной организации, на scala 2.11 Хотелось бы в штат. Есть удалёночка, но только из РФ. Основной офис в Ижевске, но проект по московскому времени.

Стек проекта: Scala, Akka, PlayFramework, PostgreSQL, Confluence, Open Project, Kafka, RabbitMQ, КриптоПРО, Liquibase, Squeryl.

По деньгам, 150 тыс. руб. в мес. на руки для мидла, 250 за сениора. Но это не верхние границы, если у вас богатый профильный опыт и портфолио, можем рассмотреть более высокие зарплаты.

Резюме, сопроводительное письмо и желаемую зарплату прошу кидать на vladimir.bychko@develonica.ru

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

* * *

О постмортемах

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

Зачем это всё надо, кроме назиданий потомкам. Столкнулись с проектом, в котором надо оказать специфическую услугу. Так как стоимость довольно высокая, заказчик решил провести тендер. И для подачи документации на этот тендер, надо представить доказательства того, что мы такую услугу ранее оказывали.

Бегаем по всей компании, вытаскиваем из олдфагов воспоминания.

Пишите постмортемы, короче.

* * *

Об орущих сайтах

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

Сайт с очень крупной типографикой.

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

Мелкие сайты из старого веба трудно читать, нужно напрягать глаза, современные на тебя орут. Комфорт, как обычно, где-то посередине.

* * *

О принятии решений

Подумал, что есть ещё один важный навык, которому не учат ни в школе, ни в институте (по крайней мере, в виде части какого-либо курса или предмета), но который очень важен в реальной практике. Это принятие решений.

В целом, в школе, существует один способ решения задач в точных науках и общепринятое мнение для работ по гуманитарным. Если принять решение решить задачу альтернативным методом или написать сочинение с необщепринятым мнением, могут снизить оценку.

В вузе чуть более выраженная свобода и микрорешения всё же присутствуют. Например, я иногда принимал решение вообще не идти на сдачу экзамена, а идти сразу на пересдачу, где оценка будет снижена на балл, но и требования сильно ниже.

Но хотелось бы, чтобы осознанному принятию решений всё же обучали.

* * *

О задачах с несколькими заинтересованными лицами

«Проектные» люди часто решают плохоформализованные задачи, в которых участвует несколько человек, иногда из разных организаций. Если вам спихнули такую задачу, которой ранее уже занимались и вам её надо добить, не ломитесь как лось на гону её решать, прежде чем свяжетесь с каждым из затронутых лиц и уточните, что они о ней знают. Могут быть сюрпризы.

* * *

Об учёном

Когда говорят «Калининград», большинство вспоминает янтарь и Канта. Более продвинутые люди вспоминают строганину, клопсы и марципан. Но дело в том, что в Кёнингсберге родился и провёл изрядную часть научной карьеры ещё один крайне важный учёный.

Давид Гилберт, последний универсалист в математике и один из важнейших математиков двадцатого века. Как Ландау понимал всю известную на тот момент физику, так Гилберт понимал всю математику и сделал большое количество открытий в разных её областях.

Кроме того, Гилберт сформулировал и представил в 1900 году «23 проблемы Гилберта», 23 важнейшие математические задачи двадцатого века. После него другие учёные предлагали свои списки, но гилбертовский считался наиболее трушным. Надо сказать, что человечество оказалось молодцом и решило 16 задач. Ещё две не являются математически корректными, ещё три решены для частных случаев и ещё две не решены вообще.

В общем, Калининград/Кёнигсберг — это не только Кант, но и Гилберт.

Давид Гилберт, портрет.
Давид Гилберт

* * *

Об ещё одном учёном

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

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

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

Илья Романович Пригожин.

* * *

О дефектах речи

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

Сейчас встретил команду, в которой практически все слегка картавят.

* * *

О стариках

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

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

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

Ладно, у Яндекса есть какой-то аналогичный чебурнетный редактор, так что совсем без онлайн-документов не останемся, но тренд прослеживается.

* * *

О багах в основном потоке

У нас хорошая цифровизация органов власти. Очень мало в каких странах есть аналоги Госуслуг и других онлайновых государственных сервисов. Но всё равно, постоянно сталкиваешься с багами в основном потоке.

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

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

С десктопного сайта всё работает.

* * *

О письме вымышленному другу

Есть такой программистский приём по преодолению затруднений — взять резиновую уточку и максимально подробно описать ей свою проблему. Часто решение приходит само собой.

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

* * *

О священности введённых пользователем данных

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

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

Хороший кейс — пару недель назад пытался надеть фиолетовый ошейник в Линке, ввёл данные о компании и вакансии, но завершить процедуру не удалось, Линк не принимал код. Саппорт сказал, что из РФ больше нельзя создать вакансию, их борьба. Так вот, если попытаться сделать это ещё раз, окажется, что Линк сохранил все данные. Няшки.

* * *

О живом общении

Илья Бирман как-то раз написал (а я утащил это себе в «Правила жизни»), что не бывает «удалённой» и «приближённой» работы. Есть просто работа и просто присутствие в офисе, иногда эти процедуры пересекаются.

Точно так же с общением. Многие пишут в анкете на СЗ — «только живое общение». Мне кажется, в 2к23, нет никакого «живого» и «мёртвого» общения, есть просто общение, и совершенно не имеет значения, по какому каналу оно происходит.

Более того, общение в мессенджерах даже более полезно для истории. Однажды археологи обнаружили письмо, в котором римский солдат Антоний Максим Апион 2000 лет назад написал своему отцу Епимаху. Прикрепляю к посту. Так же в будущем цифровые археологи будут раскапывать наши переписки и по ним восстанавливать картины быта 21 века.

Переписка Апиона с Епимахом, древний Рим.

* * *

О разнице русского и китайского взглядов на бизнес

Когда-то читал историю (похожую на притчу) о разнице русского и китайского взглядов на бизнес. Человек рассказал, что устроился в новый офис и всё время проходил мимо ларька с пирожками. И на этом ларьке было объявление: «Ксерокса нет». Через несколько дней объявление сменилось на «Ксерокса нет и никогда не было». Потом вывесили: «Ксерокса нет и мы не знаем, где ксерокс». Ещё через несколько дней: «За вопрос о ксероксе — штраф 1000 руб.»

А потом этот киоск купил китаец. Через три дня работы он притащил откуда-то самый дешёвый чёрно-белый ксерокс. Где-то через неделю заменил его на нормальную МФУ с цветной печатью. Через месяц поставил компьютер, фотокамеру, фон и сделал что-то вроде маленького документального центра со сканированием, распечаткой, фото на документы, доступом к электронной почте и прочим. Через полгода пристроил к ларьку небольшое кафе и начал строить парикмахерскую. Перестал приезжать на велике и обзавёлся подержанным джипом.

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

* * *

О санкциях со стороны телеграма

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

Но могут и за более безобидные вещи. Наш региональный новостной канал запостил новость: «Российские учёные объяснили причины аварии лунного модуля — он разбился о поверхность Луны».

Клопс о Роскосмосе.

Я не удержался и запостил в комментариях мем: «Я ёбнулся с саней», посчитав это достаточно ироничным.

Я ёбнулся с саней, мем.

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

Посмотреть, на какое время вы наказаны, можно у бота @SpamBot Снять наказание досрочно нельзя никак. В общем, если используете телегу по работе, будьте осторожны.

* * *

О передастии и паузах

Если вы не топ-менеджер, в вашей работе будет так или иначе присутствовать передастия. Например, верхнеуровневые финансовые вопросы чаще всего пиэмам не доверяют. И вообще, иногда приходится транслировать подчинённым решения вышестоящего руководства и никуда от этого не деться. Маленький лайфхак — немного тупите.

«Мне сказали — я сказал. Мне бы не говорили — я бы не говорил» — из ролика «Порожняк», киножурнала «Фитиль». Не торопитесь перекатывать вагончики, в изрядном проценте случаев сэкономите силы и нервы команды.

Я не о саботаже, конечно, а о небольшом временном буфере. Получили решение от руководства — ну не передавайте его никому полчаса, потупите. Не придётся извиняться, когда это решение отменят.

* * *

О дожимании

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

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

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

В общем, умение дожимать — одно из важнейших для проектных сотрудников. Оно важно и для исполнителей, но для пиэмов первостепенно.

* * *

О проверке бизнес-гипотез изнутри

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

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

* * *

О мобилках

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

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

Может быть, второе дыхание дадут последние ходы эппла с переориентацией айфона в игровую платформу?

* * *

О важности альтернативного мнения

Сейчас в нашем обществе не то, что не приветствуются альтернативные мнения, за них жестоко наказывают. Могут наказать простого гражданина, давшего неправильный ответ во время уличного опроса, могут наказать депутата, нажавшего на неправильную кнопку во время голосования в Думе, исключений нет. Волшебное слово «дискредитация».

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

С другой стороны, обществу такое положение дел удобно и комфортно. Чтобы разбираться в нескольких точках зрения, нужно мыслить, а мыслить тяжело. Для аналогии — вы прекрасно знаете, как трудно заставить себя после работы сходить в спортзал, причём, независимо, умственная это была работа или физическая. Прилечь на диванчик и смотреть тиктоки легче. С мышлением то же самое, принять единственно верную точку зрения и жить с ней намного легче, чем пытаться понять, в чём разница между несколькими, какие у них плюсы и минусы. Обратите внимание, на выборах уже давно нет носителей различных государственных программ, более того, нет вообще никаких программ, даже формальные кандидаты высказывают одни и те же популистские лозунги и всё.

Если общество людей, не посещающих спортзал ещё имеет какие-то перспективы, то общество людей с дряхлыми мозгами перспектив не имеет.

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

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

Делать выбор и нести ответственность за этот выбор, другого пути нет.

* * *

О пользе генеративных нейросетей для создателей инди-игр

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

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

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

Апдейт. К сожалению, автор канала запретил встраивание своих постов, поэтому буду просто цитировать.

Чел сделал небольшую игру, используя Dalle-3 для графики, а ChatGPT-4 для написания кода.  

Сделать свою несложно: генерим сначала картинки персонажей, врагов, снарядов и фон в Dalle-3. Потом берем все картинки, идем в ChatGPT-4 и пишем промт: 

You are an expert software developer and you want to code a very simple 2D game. [подробности игры]. Think step by step to start coding it. I will provide you in later iterations with the different images. For now, you can just use squares with different colors for the characters

ИИ пошагово все сделает. Поздравляю, вы разработчик игр.

Источник.

* * *

Об интересных задачах для школоты

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

Кешбэк Альфы 1 % за всё + 5 % за такси при выборе месячной категории. Кешбэк рублями.
Кешбэк Яндекса за заказ Комфорт теперь 5 % при оплате банковской картой и 10 % при оплате картой Яндекс Пей (предполагаем, что у вас есть подписка Яндекс Плюс). И это кешбэк баллами Яндекс Плюс, вы его можете тратить только на оплату некоторых сервисов Яндекса. Но при оплате картой Яндекс Пей, вы теряете банковский кешбэк.

Что выгоднее:
Заказывать Эконом и получать только банковский кешбэк рублями?
Заказывать Комфорт (он дороже на 10-20 %), оплачивать картой Альфы, получать кешбэк Альфы рублями и Яндекса баллами Яндекс Плюса?
Заказывать Комфорт, оплачивать картой Яндекс Пей и получать повышенный кешбэк, но баллами Яндекс Плюса?

* * *

О проектах, которые на самом деле не проекты

Однажды я оказался на проекте, в рамках которого нужно было реализовать одно государственное требование по маркировке продукции. Но прежде, чем что-то проектировать и кодить, требовалось изучить группу процессов, описать их «как есть» и если необходимо, внести корректировки. Потому что никто не знал их целиком, были отдельные лица, знавшие отдельные процессы (не всегда во всех деталях).

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

Меня поставили пиэмом и первым делом потребовали план. Я связался с архитектором и предложил вместе составить план работ. Он отвечает: «Мы не можем составить план, высокая неопределённость. Совершенно непонятен конечный объём работ, после каждых выполненных задач вылезают новые задачи, надо просто работать, пока всё не опишем и не зафиксируем». Я предложил работать «набегающей волной», составив приблизительный перечень работ на будущее и детально расписав задачи на ближайшее время. Архитектор ответил, что задачи на ближайшее время переписать можно, но их список постоянно меняется, буквально каждый день.

Руководство в ответ на составленный мной «план», заявило, что они не работают по спринтам, у них сплошной водопад, требуется нормальный план с диаграммой ганта. Что такое «высокая неопределённость», которую мы поэтапно уменьшаем, им непонятно.

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

Закончилось это тем, что я на очередной встрече по статусу испытательного срока сказал, что не хочу далее этот испытательный срок проходить и наше сотрудничество закончено.

Сейчас смотрю на ситуацию ретроспективно и понимаю одну вещь. Наша деятельность просто не была проектом и методы проектного управления к ней были неприменимы, вот и всё.

* * *

О заботе об инструментах

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

И только для человека, зарабатывающего при помощи других людей, то есть, руководителя, эта мысль почему-то неочевидна. Растворимый кофе (на который нужно скидываться), наидешевейший компьютер с монитором, на котором можно разглядеть пиксели с двух метров, «стул для посетителей» вместо кресла — стандартная практика большинства работодателей. Я в итоге стал отказываться от рабочего компа и всё делать на своём макбуке. Если бы офисные времена не закончились, купил бы ещё и рабочее кресло, так достала боль в спине по окончании рабочего дня.

Если зарабатываете при помощи людей, заботьтесь об этих людях. Овёс, навес, подковы, морковка и яблочко, должны быть надлежащего качества.

* * *

О чиновничьем аппарате

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

Параллельно с этой структурой, есть структура Министерства Просвещения, а чтобы эти структуры не расслаблялись — Рособрнадзор, который всё это контролирует и выделенные сотрудники прокуратуры, чтобы тоже контролировать, но по-другому.

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

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

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

Но такой задачи пока не стоит. Прилагаю кусочек «Законов Паркинсона», чтобы показать, что такое не только у нас и не только в образовании.

Законы Паркинсона, численность чиновников Адмиралтейства.

Что менеджеру проектов нужно знать об ИСР

Изображение с диска «Реклама и коллаж», автор Lynn Stephenson

Несмотря на то, что проектами можно считать и простенькие активности, состоящие из трёх-четырёх работ, в реальных проектах их обычно сильно больше. Даже для простенького мобильного приложения можно выделить до сотни конечных работ. Для их представления нужна ИСР, иерархическая структура работ или, по-английски, WBS, work breakdown structure. В этой статье подробно разберём все аспекты подготовки этого проектного артефакта.

В целом, всё просто. Проект разбивается на отдельные работы до тех пор, пока не получатся атомарные задачи. Насколько мелкими должны быть конечные задачи? В каждой компании свой подход к этому. Кто-то требует, чтобы задача умещалась в 8 часов. Кому-то достаточно, чтобы задачу мог выполнить один сотрудник.

Вы можете создавать ИСР и для личных дел, включающих много аспектов. Вот, например, ИСР, которую я составил, когда переезжал на новую квартиру:

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

Что же касается «взрослых» проектов, термин был впервые употреблён в 1993 году в США.

Теория

Графическое представление ИСР выглядит нагляднее, чем обычный список, благодаря возможности сворачивать и разворачивать узлы структуры.

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

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

Также ИСР позволит выявить связи между работами.

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

Важные принципы составления ИСР

Иерархическая структура работ проекта строится на следующих принципах:

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

Алгоритм создания ИСР

Можно создавать ИСР в одно лицо, но я обычно привлекаю аналитика на начальных этапах и лидов компонентов (фронт, бэк) на более поздних (для нормальной декомпозиции). В целом же, порядок таков:

  1. Идентифицировать конечную цель проекта, по идее, это должен быть некий уникальный продукт. И разместить эту цель в корне иерархии.
  2. То, что мы сделали на предыдущем этапе, декомпозировать на понятные и достижимые компоненты первого уровня. И разместить их на первом уровне.
  3. По тому же принципу сформировать второй, третий уровень. Четвёртый — это уже многовато, если вы задумались о четвёртом уровне, может быть, стоит разбить проект на подпроекты?
  4. Назначить ответственных за каждую работу.
  5. Готово, вы восхитительны ♥️

Крайне важно, чтобы работы были смартовыми.

Крайне важно сделать систему кодировок работ. 1 для корня, 1.1 для первого уровня, 1.1.1 для второго и так далее.

Формы представления ИСР

Если это (требования, отчёт, план) не помещается на одной странице – никто этого не поймёт.

Марк Ардис

Stevens Institute of Technology

Очень важно, чтобы ИСР удобно и читабельно отображалась. Мне известны следующие форматы представления:

  • Контурная структура. Просто список с уровнями. Самая простая в разработке и самая неудобная для просмотра структура.
  • Иерархическая таблица. Делается в экселе или гуглодоках. В первом столбце корень, во втором — первый уровень, во втором — второй. Когда уровни заканчиваются, в таблицу можно занести ответственных оценку и всё, что пожелаете. Тоже относительно просто делается, в использовании немного удобнее предыдущего варианта.
  • Древовидная структура. Делается в программах для деловой графики, Visio для обладателей компа на винде, Draw.io для всех остальных. Или можно использовать софт для майндмапов. Графически представляем все уровни, появляется возможность сворачивать и разворачивать узлы. Это уже совсем удобная штуковина.
  • Диаграмма Ганта. Это следующий этап работы. ИСР с проставленными ответственными, связями, оценкой сроков. Обычно делается в Microsoft Project. Я когда-то делал в Merlin Project.

В целом, это всё, что пиэму нужно знать об ИСР.

Как провести собеседование на менеджера проектов

Собеседование на менеджера проектов.

В сети есть огромное количество материалов о том, как правильно проходить собеседования на менеджера проектов, но мало кто пишет, как собеседования проводить. На что обращать внимание? Какие вопросы задавать? Как интерпретировать ответы?

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

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

Спросите, что кандидат уже знает о компании. Серьёзные люди, помимо внимательного изучения вакансии, находят сайт компании, более-менее разбираются, о чём она. Несерьёзные обычно отвечают уклончиво.

Поинтересуйтесь, как у кандидата дела с поиском работы, много ли собеседований, есть ли уже какие-то конкретные варианты, можно без подробностей.

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

Обычно рекрутер на этапе скрининга отсеивает большинство непрофильных кандидатов и на встречу с вами приходят уже люди, более-менее в теме. Вам решать, задавать ли совсем простые, фильтрующие вопросы, вроде: «Что такое проект» или: «Чем скрам отличается от канбана»

Ещё один типовой вопрос для отсеивания случайно прошедших скрининг нубов, что нужно делать, если не успеваем в срок. Грамотный кандидат расскажет пять-шесть методов сжатия расписания, неграмотный будет блеять про привлечение дополнительных разработчиков.

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

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

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

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

Если для роли пиэма в вашей компании требуется технический бэкграунд, можете задать несколько технических вопросов. У меня есть пост с вопросами для собеседования на технического менеджера проектов.

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

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

Поинтересуйтесь, как скоро кандидат сможет выйти на работу, если получит оффер.

Напоследок расскажите претенденту дальнейшие действия. Будут ли ещё собеседования с другими членами команды или руководством (этим грешат крупные компании), как скоро он получит обратную связь. Поблагодарите за уделённое время и попрощайтесь. Нормальное время собеседования — сорок-пятьдесят минут, за это время можно выяснить всё необходимое.

Изображение с redbubble.com

Выбор подрядчика для разработки приложения

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

У вас четыре варианта подхода к найму исполнителей. 

  1. Инхаус-команда.
  2. Один или несколько фрилансеров. 
  3. Аутстаф команда под полным вашим контролем. 
  4. Подрядчик, которому вы поручаете работу под ключ. 

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

Инхаус команда

Создаём штатные единицы исполнителей, поручаем рекрутеру найти кандидатов в штат. Вносим им записи в трудовые книжки, платим зарплату. 

Вариант хорош, когда приложение планируется очень сложным и дорабатывать его предполагается длительный период (в нынешних условиях «длительно» — это 2-3 года). По деньгам вариант получается чуть ли не самым дешёвым, дешевле только фрилансеры. 

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

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

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

Один или несколько фрилансеров

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

Чаще всего, фрилансеры не требуют договор. Есть пространство для бухгалтерских манёвров с расходами на них. Нет официального оформления отношений — в ваших руках большая свобода в формировании команд и их переформатировании. 

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

Ранее практиковался найм разработчиков-фрилансеров из Украины, они стоили ещё дешевле, относительно российских. Но теперь этому мешает СВО и препятствия для трансграничных переводов. 

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

Аутстаф команда под вашим контроем

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

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

Недостаток метода в дороговизне. Аутстаферам нужно платить специалистам зарплаты и при этом что-то зарабатывать, поэтому это самый дорогой вариант. 

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

Подрядчик для работы под ключ

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

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

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

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

На практике рассмотренные методы хорошо и правильно комбинировать. Например, нанять инхаус лидов, а для исполнителей использовать аутстаф.

Как грамотно передать проект другому менеджеру

Передача проекта
Изображение с сайта insplash.com, автор Jael Rodriguez

Получить проект в свои руки с самого начала — большая удача. Намного чаще случается, что вы устраиваетесь в новую компанию и вам проект передаёт один из штатных менеджеров. Либо вы увольняетесь и передаёте проект коллеге.

Я решил собрать в одной ментальной карте все аспекты и вопросы, которые нужно учесть при такой передаче. Вот вам pdf:

А вот исходный файл (Minjet Mindmanager).

Вот ещё хороший пост про передачу дел:

1

Пять признаков проекта, который провалится

Подавляющее большинство проектов проваливается. Понять, что данный проект провалится, не очень сложно. Есть несколько маячков.

Дедлайн спущен сверху

В практике постоянно натыкаюсь на ситуации, когда высокое начальство поговорило и решило, что срок 15 октября этого года. Или 2 ноября. Или 28 декабря. Как оно это посчитало — непонятно, потому что никаких планов нет даже близко, ещё даже не вполне понятен набор фич продукта.

Иногда дата, действительно, оправдана. Например, с 15 октября меняется форма отчёта, а продукт как раз и делается, чтобы генерить отчёты по новой форме. После 15 октября делать отчёты по старой форме бессмысленно.

Чаще же она привязывается к старту какой-нибудь маркетинговой активности или ещё какой-нибудь ереси из мира высокого начальства. У РМ-а же, как правило, возможности отказаться делать проект к данной дате нет и приходится выкручиваться.

Я делал такие проекты. Приходилось подключать дополнительные ресурсы, максимально упрощать фичи, экономить на качестве. Как правило, это приводило к тому, что проект был либо сдан вовремя, либо с небольшим опозданием, однако пользоваться продуктом было невозможно из-за багов и наступали «вторые 90 % проекта», когда попеременно наши тестировщики и приёмщики заказчика шлют баги, а разработчики их мужественно правят.

В общем, если дедлайн спускается сверху без точных расчётов, проект, скорее всего, провалится.

Планируют и реализуют разные люди или даже подразделения

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

В отличие от материального труда, где производительность сотрудников различной квалификации примерно сравнима (нельзя, например, нанять сениора плиточника, чтобы он за ночь обложил вам плиткой большую ванную комнату, если реально там труда на несколько дней) и сотрудники относительно взаимозаменяемы, в разработке так нельзя. Сениор может кодить быстрее мидла не в два, не в четыре раза, а на порядок. Да ещё и допускать в коде меньше дефектов. И специалисты примерно одной квалификации могут сильно различаться по производительности.

Иными словами, оценивать должен тот, кто будет кодить/дизайнить/описывать требования. Иначе проект начнёт проваливаться очень быстро.

Руководитель проекта недостаточно квалифицирован или мотивирован

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

Менеджеру проекта должно быть «больше всех надо». Именно он должен предвидеть, беспокоиться, подскакивать кабанчиком, обкашливать вопросики. Поэтому у него должно быть ограниченное количество проектов. Фактическое число зависит от квалификации, для меня оптимальны два крупных или один крупный и штук пять мелких, не требующих много внимания. Для другого менеджера эта цифра может оказаться другой. РМВОК, вообще, регламентирует, что в зрелой с точки зрения проектного управления компании, РМ полностью сфокусирован на одном проекте.

С недостаточной квалификацией всё ещё прозрачней. Джуну РМ-у лучше ограничиться лендингами за 3000 руб. или простенькими интернет-магазинами и копить опыт. Если действовать по принципу отца, сбрасывающего сына с лодки, всегда есть риск провала. Ну, или того, что сын научится писать и напишет на незадачливого отца заявление в милицию.

Не определились с особенностями реализации проекта

Бывает, что важные особенности проекта держатся в неопределённом состоянии на стадии первичной или даже точной оценки, а иногда на них забивают даже после старта работ.

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

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

Не определены специфические критерии успешности проекта

Обычно успешным проектом считается проект, который удалось запихнуть в треугольник сроков, денег и качества. Однако бывают проекты, на которых, к примеру, срок важнее других параметров. Как в примере, о котором я писал выше. Ну кровь из носу нужно к 15 октября иметь инструмент для генерации отчётов новой формы. И ничего страшного, если мы потратим немного больше денег или в продукте будут отдельные некритичные баги. А бывает наоборот, запуск проекта связан с репутационными рисками и лучше выпустить продукт попозже, но без багов.

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

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

Устав или паспорт проекта

Паспорт или устав проекта

Уставом или паспортом проекта называется внутренний договор менеджера проекта со спонсором. Он содержит неизменные параметры проекта. Изменяется устав — перезапускается проект.

Предположим, вы с друзьями решили поиграть в футбол. Предполагается, что во время игры мяча касаются только ногами и головой. Нельзя во время игры внезапно разрешить брать мяч руками. Но можно остановить игру в футбол, зафиксировать счёт и начать новую игру в гандбол, в которой мяч руками брать можно и нужно.

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

В первую очередь, устав защищает менеджера от поползновений вида: «Дай мне, пожалуйста, трёх программистов, на другом проекте очень надо». Меняется численность команды — перезапускается проект.

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


Что должно входить в состав устава?

  • Название;
  • Имя спонсора;
  • Имя менеджера;
  • Основные проектные цели;
  • Треугольник ограничений;
  • Перечень ресурсов, выделяемых в распоряжение проекта;
  • Главные заинтересованные лица (не дублировать реестр заинтересованных лиц, перечислить только ключевых);
  • Главные результаты поставки;
  • Основные KPI;
  • Ключевые (терминирующие) риски.

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

Ограничения следует формулировать в терминах «не более, чем». Это рамки, при выходе за которые проект теряет смысл.

В правилах игры в футбол написано, что мяч нельзя брать руками, при выходе мяча за боковую линию производится аут, при выходе за лицевую — угловой или свободный удар. В правилах не пишут, что команда А должна на 13 минуте перейти в атаку, причём форвард Б должен дать горизонтальный пас форварду С. Это глупо.

Из предыдущей цитаты следует, что устав не должен быть большим по объёму. Если вы сгенерили устав в 100 страниц, вы неправильно поняли его суть. Объём устава не может превышать 3-5 страниц, вне зависимости от того, строите вы трубопровод или делаете инновационный дейтинг с геолокацией. На проекте просто не бывает неизменных параметров на сотню страниц.

Ресурсы могут быть выражены в деньгах, а могут в людях. Заменимых людей рекомендуется записывать по названиям должностей (3 фронтендера), незаменимых, без которых вы не влезете в треугольник, можно и по имени.

Устав лучше всего иметь в бумажном виде. Печать организации на ней не нужна, это внутренний документ, который пределы компании никогда не покинет. А вот с подписью есть тонкий момент. Есть риск, что спонсор устав, присланный по емейлу, не прочитает. А если прийти к нему лично с бумагой и попросить эту бумагу подписать, у него включается мозг и он начинает реально читать, спорить и предъявлять претензии, а спорить о параметрах проекта лучше до его старта.


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

В таком случае в устав можно включить ссылки на окружение проекта — дев сервер, прод сервер, документацию в конфлю, роадмап, реестр рисков, реестр заинтересованных лиц и другие проектные документы.

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