Владимир Завертайлов - Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

Был случай, когда на взлете испугавшийся (или от эйфории) пассажир попытался перехватить у меня управление. Благо в RV-7 он сидел рядом, и можно было успокоить пассажира. В самолетах типа Extra, Як-52 или Су-29, где кабины разделены и посадка друг-за-другом – такой возможности нет.

Ребята рассказывали про ситуации, когда испуганная девушка-пассажир крепко зажимала сильными ногами ручку управления самолетом и на призывы: «Расслабься. Расслабь ноги. Ноги расслабь! РАЗДВИНЬ НОГИ $%^^…!!!» – реагировала слабо.

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

Да, есть куча всяких контролирующих органов, транспортной прокуратуры, проверок, центров сертификации, подач планов, диспетчеров, техников, метеорологов, и всякого такого. Но как только ты – КВС (командир воздушного судна) и принимаешь решение о взлете – ВСЯ (ВСЯ!) ответственность на тебе. Отмазки не канают. Никакие.

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

Брать на себя всю ответственность – это, кстати, прикольное чувство, попробуй.

Чем больше ты летаешь – тем больше будет разных ситуаций.

Вот недавно знакомые летчики в районе Телецкого озера попали в облако саранчи. Одно зеленое насекомое попало в ПВД – приемник воздушного давления, который обеспечивает определение скорости относительно воздуха. Итог – отказал указатель скорости.

Скорость – наша жизнь. В горах – особенно интересно. Но ничего, сориентировались. Дошли до ближайшего аэродрома, выдерживая скорость по GPS, а изменение маршрута объяснили «санитарной необходимостью» (хорошая формулировка, емкая!).

Лучше летать много, чем 1–2 раза в год. Пожалуй, пару раз в год – это самое опасное. Либо не летай, либо летай постоянно. Да, вероятность попасть в веселую ситуацию – выше, но и опыт здесь – бесценный помощник.

То же и про управление. Занимаясь чем-то профессионально – нельзя делать это время от времени.

Так уж получилось, что Су-29, который пригнали из-за границы, два года пылился в ангаре. Самолет сложный, суровый. Летать на нем стало некому, однако с учителями везло. Познакомился с Михаилом Переверзевым, мастером спорта России международного класса, многократным призером чемпионатов России, Европы и мира… Короче, крутым парнем.

Сколько было скепсиса у него в глазах, когда я обратился к нему с просьбой о тренировках: «На таких самолетах только мастера спорта раньше летать могли, и то не все… Это не учебная машина. Эх, времена!» Тем не менее, желание вновь полетать на пилотажнике пересилило, и Михаил согласился. Каково же было наше с ним удивление, когда на третьем часу тренировок мы поняли, что я готов к самостоятельному вылету. На четвертом часу полетел сам, в сложных метеоусловиях. Самолет очень живой, и я даже на 10 % не освоил его потенциал.

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

Учить и тренировать вас никому неинтересно. И уж точно – никто не обязан вами заниматься. Это время, нервы, и в конце концов – риск. Если вдруг вас учат чему-то на работе и в рабочее время (управлению проектами, дизайну, программированию, soft skills), и вам это идет на пользу – относитесь к этому с благодарностью. А не как к само собой разумеющейся херне. В жизни очень сложно найти хороших учителей и уж тем более заинтересовать/убедить их заниматься вами. Большая удача.

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

1. Какие еще объекты вы бы добавили в картину мира digital-проекта? Что вы с ними делаете? Как они связаны друг с другом?

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

3. В течение недели попробуйте делать постановки четко по SMART, а письменные постановки с использованием принципа «пирамиды». Проверяйте их через сервис glvrd.ru.

https://www.youtube.com/watch?v=bo4i525EszY

Андрей Курпатов, «Красная Таблетка».

Максим Ильяхов, «Пиши, сокращай».

Максим Ильяхов, «Новые правила деловой переписки».

Старое интервью Стива Джобса о командной работе (ссылка спрятана в QR-коде слева).

Тикет-система– система онлайн-постановки и контроля задач.

Тикеты– собственно, задачи.

Бэклог– инструмент Скрама, по-простому – это список всех хотелок проекта, отсортированный в порядке приоритетов.

NDA– Non-disclosure agreement, соглашение о неразглашении: юридический договор, между сторонами с ограничением доступа третьим лицам к каким-либо данным и/или результату работ.

Софт– программное обеспечение, или ПО.

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

Гайдлайн– руководство по правильному использованию визуальных элементов на сайте.

Тест-план– документ, где описывается весь объем работ по тестированию проекта: как, что и когда проверять. В идеале, тест-план пишет опытный тестировщик, а выполнить тест-план способна обезьянка с мышкой.

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

Спринт– временной интервал, обычно в 2–4 недели, в течение которого scrum-команда выполняет заданный объем работы.

Рисерч – (en: research)исследование: поиск и сбор необходимой для выполнения задачи информации, проба новой технологии и так далее.

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