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

Мы намеренно пропускаем 5, 6, 7 – если такие приоритеты понадобятся на конкретном проекте, мы их просто придумаем, не ломая основную систему.

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

Есть клиенты-перфекционисты, которые считают, что нельзя выпускать проект с незакрытыми багами. Увы, в наше время это утопия. Любой софт выпускается с какой-то долей некритичных ошибок. С какой именно – это вопрос дискуссионный. Бывает, что пользователи используются как бета-тестеры. Скорость на запуске (или Time To Market, TTM – время от начала разработки идеи до ее конечной реализации) важнее. Понять это можно, посмотрев на обновления приложений, которые прилетают к вам в телефон. Большая часть обновлений в описании содержит две строчки: «Увеличена стабильность, улучшена производительность». На русский язык переводится как: «Мы поправили пару багов». Даже у Apple ошибки, которые известны годами, – это норма.

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

Было ли у вас такое, что вы моете посуду, а вам все время подкидывают новую? Опа, а тут еще и сковородка! Это откровенно бесит. Я считаю, что программисты должны видеть конечный набор багов и задач. Поэтому, если тикетов много, стоит организовать работу мелкими итерациями (спринтами). И даже если параллельно с исправлением багов идет процесс тестирования, то новая пачка багов должна попасть к программистам, только когда они отработают и закроют уже выданный им объем. Это не всегда возможно и не везде применимо, но стоит к этому стремиться, потому что так в итоге спокойнее.

1. Маты и КАПС. Вам – нельзя. Разработчикам – иногда можно.

2. Место.Указывайте конкретное место, где возникла ошибка.

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

4. Пирамида.Используйте принцип пирамиды. Важное – в начало. Детали – в кончало.

5. Скриншоты – важное дополнение.Подкрепите текстовое описание скриншотом.

6. Решение, а не мнение.Формулируйте не только проблему, но и ожидаемое решение – четко и однозначно, а не в виде абстрактных пожеланий и мнений.

7. Не впадайте в истерику.Пишите по делу, без эмоций.

8. Приоритизируйте.Расставляйте приоритеты и организуйте по большим баг-листам работу микро-спринтами.

9. Закончите уже!Не подкидывайте посуду!

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

В авиацию я попал не через авиацию, а почти случайно. Просто повезло столкнуться с правильными людьми. С тех пор прошло несколько лет. Кроме самолета освоил вертолет, посчастливилось полетать по Алтаю, освоить строгий спортивный самолет Су-29, 3-ю лигу по пилотажу, поучаствовать в паре авиашоу. Летаю меньше, чем хотелось бы, и до сих пор чувствую себя дилетантом. Постоянно узнаю новое. Этот опыт меняет картину мира в управленческой работе над digital-проектами.

Как правило, самолеты должны обслуживать специально обученные техники. Их у нас мало.

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

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

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

Я видел в проектах, когда море сил тратится на иллюстрации (в том числе – 3D), а по итогу – ну да, картинка и картинка. И наоборот, когда стоковое видео или фото в банальном слайдере вызывает реакцию: «Вау! Какой дизайн!»

В авиации мелочей не бывает. Никаких. Нигде. Любая мелочь может тебя угробить.

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

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

Ориентируюсь: поджопник с пассажирского кресла заблокировал дублирующую ручку управления. Как позже оказалось – за зиму высох клей. Благо, в RV-7 пассажир и пилот сидят бок о бок, ситуацию удалось мгновенно исправить.

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

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