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

Страховая: Эй, клиент, купи у меня страховку, а когда у тебя случится беда, я помогу деньгами.
Клиент: Хорошо, вот деньги.
…
Клиент: Эй, страховая, у меня случилась беда, теперь ты мне поможешь?
Страховая: Нет :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 делаете приложение, чтобы заработать, нужен собственный могучий источник трафика или какой-нибудь арабский шейх с неограниченными деньгами для закупки трафика. Да и то, не факт, что экономика сойдётся.

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

* * *

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

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

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

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

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

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

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

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

* * *

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

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

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

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

* * *

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

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

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

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

* * *

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

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

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

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

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

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

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

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

* * *

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

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

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

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

* * *

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

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

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

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

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

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

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

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

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

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

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

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

Теория

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---

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

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

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

Kick-off – значит «вбрасывание». Если вы работаете в маленькой компании, где все постоянно друг с другом взаимодействуют, нужды в kick-off совещании нет, но если мы говорим о крупной, с отделами и департаментами, оно необходимо.

Этим совещанием начинается работа по проекту, прошедшему фазу инициации и планирования. То есть, сформирован устав и концепция проекта, написан план работ, издан приказ о старте проекта.

1. Собираем всю команду в одном месте. Если команда распределённая — созваниваемся, но эта практика больше для офисных команд.
2. Зовём спонсора проекта. Очень важно, чтобы он пришёл, сказал приветственное слово и сразу же ушёл. Нужно для придания официальности мероприятию.
3. Просим каждого члена команды встать, представиться и назвать свою роль. В больших компаниях, особенно с большой текучкой, есть вероятность, что кто-то кого-то не знает, а после такой инициализации появляется вероятность, что ранее незнакомые люди будут контачить.
4. Спрашиваем, все ли видели устав проекта и приказ о старте. Просим поднять руки всех, кто не видел. Если такие есть, даём им доступ и присылаем ссылку.
5. Спрашиваем, все ли видели план работ и ознакомились с ним. У плохого менеджера член команды говорит: «Я закончил, что делать дальше?». У хорошего же: «Я закончил с этапом x и, в соответствии с планом, приступил к этапу y».

Всё, на этом расходимся. Kick-off совещание короткое, на нём необязательно вести протокол, но оно очень чётко даёт понять всем участником команд, что проект начат и всё серьёзно.