скачать книгу бесплатно
В авиацию я попал не через авиацию, а почти случайно. Просто повезло столкнуться с правильными людьми. С тех пор прошло несколько лет. Кроме самолета освоил вертолет, посчастливилось полетать по Алтаю, освоить строгий спортивный самолет Су-29, 3-ю лигу по пилотажу, поучаствовать в паре авиашоу. Летаю меньше, чем хотелось бы, и до сих пор чувствую себя дилетантом. Постоянно узнаю новое. Этот опыт меняет картину мира в управленческой работе над digital-проектами.
1. Все, что можно – проверяй сам
Как правило, самолеты должны обслуживать специально обученные техники. Их у нас мало.
Да, есть специальные чек-листы проверки самолета перед вылетом. Обойди самолет, все проверь, все пошатай, бла-бла-бла… Но есть и фактор разгильдяйства. Ребята рассказывали про забытые техником в самолете пассатижи. Рули переклинило. В тот раз обошлось, летчик чудом посадил машину. В авиации, если ты хочешь жить и летать долго – ты просто обязан проверять все сам.
Делаешь проект, управляешь проектом – да, у тебя есть команда, которая вроде как все смотрит, видит, знает, тестирует. Но глуп и беспечен тот руководитель, который только и делает, что верит всему на слово. Не проверит проект лично, на себе. Не сложит своего мнения о происходящем.
2. Зрелищно – не всегда круто
Из опыта участия и наблюдения за авиашоу – публику больше всего заводят проходы на предельно-малых высотах с грохотом и дымами (восторг!). Технически сложные фигуры и обратный (красный) пилотаж, когда от перегрузок лезут глаза на лоб – любят, но не ценят пропорционально тем усилиям, с которыми даются эти фигуры. Например, штопорные бочки – крайне противные фигуры, съедающие все силы. Но они не настолько вау-эффектные. Профессионал оценит. Публика – нет.
Я видел в проектах, когда море сил тратится на иллюстрации (в том числе – 3D), а по итогу – ну да, картинка и картинка. И наоборот, когда стоковое видео или фото в банальном слайдере вызывает реакцию: «Вау! Какой дизайн!»
3. Мелочь ничего не прощает большому
В авиации мелочей не бывает. Никаких. Нигде. Любая мелочь может тебя угробить.
Незакрытые лючки в полете или незакрытый фонарь, недотянутая гайка, и дальше уже ситуация развивается быстро, и, как правило, хреново.
Как-то после зимы я выполнял тренировочный полет. Ремни на пассажирском месте были благоразумно пристегнуты. Все пять раз проверено. Выполняю фигуру «вертикаль» (самолет летит вертикально вверх, теряет скорость, вверху переворачивается и летит вертикально вниз, быстро набирая огромную скорость). На выходе из вертикали ручка управления вдруг становится невероятно тугой, самолет еле слушается.
Ориентируюсь: поджопник с пассажирского кресла заблокировал дублирующую ручку управления. Как позже оказалось – за зиму высох клей. Благо, в RV-7 пассажир и пилот сидят бок о бок, ситуацию удалось мгновенно исправить.
Ты можешь сделать круто на своем проекте глобальные вещи. Но мелочи – это то, что может погубить твой проект. Обращай внимание на каждую деталь, какой бы мелкой и незначительной она ни казалась. Мелочи – это то, что может стать большой проблемой, если вовремя на них не отреагировать.
4. Тщательно выбирай, кого брать на борт
Я очень избирательно отношусь к пассажирам-покатушникам на борту и очень тщательно их инструктирую. Вряд ли возьму незнакомого или показавшегося хоть в чем-то неадекватным человека.
Был случай, когда на взлете испугавшийся (или от эйфории) пассажир попытался перехватить у меня управление. Благо в RV-7 он сидел рядом, и можно было успокоить пассажира. В самолетах типа Extra, Як-52 или Су-29, где кабины разделены и посадка друг-за-другом – такой возможности нет.
Ребята рассказывали про ситуации, когда испуганная девушка-пассажир крепко зажимала сильными ногами ручку управления самолетом и на призывы: «Расслабься. Расслабь ноги. Ноги расслабь! РАЗДВИНЬ НОГИ $%^^…!!!» – реагировала слабо.
Кто у тебя будет на проекте, и как он себя поведет – от этого во многом зависит будущее твоего проекта. В идеале, у тебя должна быть возможность менять членов команды, особенно если ты головой отвечаешь за результат.
5. Вся ответственность, один черт, на тебе
Да, есть куча всяких контролирующих органов, транспортной прокуратуры, проверок, центров сертификации, подач планов, диспетчеров, техников, метеорологов, и всякого такого. Но как только ты – КВС (командир воздушного судна) и принимаешь решение о взлете – ВСЯ (ВСЯ!) ответственность на тебе. Отмазки не канают. Никакие.
Ты управляешь проектом (или компанией) и позволяешь себе оправдания, типа «ой, я тут всего лишь не посмотрел/не подумал», или любишь переваливать ответственность на внешние обстоятельства, сложного заказчика или рукожопых исполнителей? Сорян, тогда рано тебе еще этим заниматься.
Брать на себя всю ответственность – это, кстати, прикольное чувство, попробуй.
6. Летать больше – безопаснее, чем летать мало
Чем больше ты летаешь – тем больше будет разных ситуаций.
Вот недавно знакомые летчики в районе Телецкого озера попали в облако саранчи. Одно зеленое насекомое попало в ПВД – приемник воздушного давления, который обеспечивает определение скорости относительно воздуха. Итог – отказал указатель скорости.
Скорость – наша жизнь. В горах – особенно интересно. Но ничего, сориентировались. Дошли до ближайшего аэродрома, выдерживая скорость по GPS, а изменение маршрута объяснили «санитарной необходимостью» (хорошая формулировка, емкая!).
Лучше летать много, чем 1–2 раза в год. Пожалуй, пару раз в год – это самое опасное. Либо не летай, либо летай постоянно. Да, вероятность попасть в веселую ситуацию – выше, но и опыт здесь – бесценный помощник.
То же и про управление. Занимаясь чем-то профессионально – нельзя делать это время от времени.
7. Ищи наставников и оставляй следы
Так уж получилось, что Су-29, который пригнали из-за границы, два года пылился в ангаре. Самолет сложный, суровый. Летать на нем стало некому, однако с учителями везло. Познакомился с Михаилом Переверзевым, мастером спорта России международного класса, многократным призером чемпионатов России, Европы и мира… Короче, крутым парнем.
Сколько было скепсиса у него в глазах, когда я обратился к нему с просьбой о тренировках: «На таких самолетах только мастера спорта раньше летать могли, и то не все… Это не учебная машина. Эх, времена!» Тем не менее, желание вновь полетать на пилотажнике пересилило, и Михаил согласился. Каково же было наше с ним удивление, когда на третьем часу тренировок мы поняли, что я готов к самостоятельному вылету. На четвертом часу полетел сам, в сложных метеоусловиях. Самолет очень живой, и я даже на 10 % не освоил его потенциал.
Помогли увидеть ошибки недавно установленные дымы. Когда за тобой дымный след – сразу видно косяки. В кабине газовая камера, жарко, пот разъедает глаза, а солнышко слепит, но ничего: назвался пилотом – терпи и тренируйся.
Учить и тренировать вас никому неинтересно. И уж точно – никто не обязан вами заниматься. Это время, нервы, и в конце концов – риск. Если вдруг вас учат чему-то на работе и в рабочее время (управлению проектами, дизайну, программированию, soft skills), и вам это идет на пользу – относитесь к этому с благодарностью. А не как к само собой разумеющейся херне. В жизни очень сложно найти хороших учителей и уж тем более заинтересовать/убедить их заниматься вами. Большая удача.
1.10. Для тренировки
Итак, мы посмотрели картину мира digital-проекта, убедились, что для нас там полно работы и посмотрели, как эту работу делегировать (не поубивав друг друга и с возрастающими шансами на успех).
1. Какие еще объекты вы бы добавили в картину мира digital-проекта? Что вы с ними делаете? Как они связаны друг с другом?
2. Понаблюдайте в течение недели на какие операции и сколько вы тратите времени и энергии. Нравится ли вам это делать, или это рутина? Вы обязаны ее делать, или можно ее кому-то делегировать? Составьте план делегирования рутины. Приводите его в действие.
3. В течение недели попробуйте делать постановки четко по SMART, а письменные постановки с использованием принципа «пирамиды». Проверяйте их через сервис glvrd.ru.
Литература
https://www.youtube.com/watch?v=bo4i525EszY (https://www.youtube.com/watch?v=bo4i525EszY)
Андрей Курпатов, «Красная Таблетка».
Максим Ильяхов, «Пиши, сокращай».
Максим Ильяхов, «Новые правила деловой переписки».
Старое интервью Стива Джобса о командной работе (ссылка спрятана в QR-коде слева).
Пояснения
Тикет-система – система онлайн-постановки и контроля задач.
Тикеты – собственно, задачи.
Бэклог – инструмент Скрама, по-простому – это список всех хотелок проекта, отсортированный в порядке приоритетов.
NDA – Non-disclosure agreement, соглашение о неразглашении: юридический договор, между сторонами с ограничением доступа третьим лицам к каким-либо данным и/или результату работ.
Софт – программное обеспечение, или ПО.
Репозиторий – место, где хранится код и вся информация о его изменениях. Репозитории могут находиться на компьютере разработчика, на компьютерах его коллег и на удаленном сервере.
Гайдлайн – руководство по правильному использованию визуальных элементов на сайте.
Тест-план – документ, где описывается весь объем работ по тестированию проекта: как, что и когда проверять. В идеале, тест-план пишет опытный тестировщик, а выполнить тест-план способна обезьянка с мышкой.
API – описание способов, которыми один сервис или программа может взаимодействовать с другим сервисом, программой или сайтом.
Спринт – временной интервал, обычно в 2–4 недели, в течение которого scrum-команда выполняет заданный объем работы.
Рисерч – (en: research) исследование: поиск и сбор необходимой для выполнения задачи информации, проба новой технологии и так далее.
Ретроспектива – собрание команды проекта, чтобы проанализировать прошедший спринт и создать план улучшений для следующего спринта.
Деплой – развертывание кода сайта на сервере.
Боевой сервер – обычно весь программный код пишется на тестовом сервере в студии, а после переносится на боевой, рабочий, сервер заказчика.
Артефакт – результат какого-то процесса: в разработке – файлы исходного кода или файлы данных, в управлении – поставленные в тикет-системе задачи.
Пересаживание обезьян – когда подчиненные свешивают своих обезьян, свои проблемы на своего босса, а тот покорно их принимает, потому что «без вас никак не разобраться» или «вам нужно подписать», или «давайте подумаем, что можно сделать» (см. «Одноминутный менеджер и обезьяны», Бланшар К., Онкен-мл. У., Берроуз Х.).
Стендап – короткая планерка менеджера с командой проекта на 10–15 минут, где обсуждаются три главных вопроса: что было сделано вчера, что будет делаться сегодня и какие есть проблемы.
Декомпозиция – разбивка большого и неповоротливого проекта по аккуратным и понятным блокам. Об этом подробнее поговорим в главе 5, посвященной декомпозированию.
Скрипт – это последовательность действий, описанных с помощью скриптового языка программирования.
Фреймворк или, по-русски, каркас – программное обеспечение, которое облегчает разработку. С ним код пишется быстрее, а в дальнейшем его проще поддерживать.
Стэк – в разработке: набор инструментов для создания проектов, который включает языки программирования, фреймворки, системы управления базами данных, системы управления контентом (CMS) и прочие используемые технологии.
Бета-тестер – почти настоящий пользователь, который интенсивно использует почти готовую версию продукта/сайта/приложения, чтобы выявить максимальное число ошибок для их последующего устранения перед окончательным выходом (релизом).
Баг – ошибка на сайте, в сервисе или в приложении.
Баг-лист – список всех найденных тестировщиком багов, который используется разработчиками для того, чтобы эти баги пофиксить (отловить и починить).
Класс – шаблон кода, по которому создается какой-то объект.
Код-ревью – процесс ревизии кода одного программиста – другим, более опытным. Цель: улучшить качество кода и обеспечить соблюдение принятых в команде стандартов.
Часть 2
Требовательность: как развивать ее у себя и своих сотрудников
2.1. Сколько программистов нужно, чтобы выкопать яму?
Давайте решим такую задачу (гротескная, но так будет веселее).
Допустим, у вас есть сотрудник, и вам по каким-то причинам нужно, чтобы он выкопал яму. Все необходимые параметры, в рамках разумного, придумайте самостоятельно.
Пока не читайте дальше, потратьте минутку для того, чтобы сформулировать (лучше вслух), как вы будете такую задачу ставить. Я подожду.
Сформулировали? Если вы использовали, например, смарт-подход и умеете развешивать контрольные точки, у вас могло получиться что-то типа: «Вася, нужно выкопать яму 30?30?30 см для захоронения офисного котика. А то он сдох, и нам тут скоро всем будет очень душно. Вон в том углу забора. Сегодня до обеда. Лопату возьми в сарае, вот тебе ключ. Справишься? А есть шанс, что не справишься?»
Теперь усугубим. Допустим, вы руководитель диджитал-проектов, а Вася – программист. Вы произносите похожую мантру (мол, выкопай яму, очень надо). Он смотрит на вас честными глазами. И говорит: «Не-хо-чу!» Ваши действия?
Первая естественная реакция: «Ну что за бред! Почему я должен уговаривать программиста заниматься непрограммистскими делами?» Потом идут попытки:
? надавить на Васю трудовыми обязанностями (облом, Вася знает, что его дело – код писать, а не ямы копать);
? уболтать на личном уровне: либо по-дружески, либо девушкиными ходами, строя глазки (облом, Вася – интроверт, идеалист и женатик);
? подкупить премией или даже напугать штрафами (не прошло, у программистов все нормально с зарплатами, а с угрозами штрафов идите вы знаете куда? – правильно, в трудовую инспекцию);
? или сослаться, что это дебильное задание дало вышестоящее руководство (совсем гнилой ход, особенно с точки зрения морали – фу так делать! – и Вася вас раскусит).
Самые чуткие, внимательные и креативные руководители проектов (а таких попадается 5–7 %) отреагируют на Васино «Не-хо-чу!». Попробуют выяснить, чего хочет Вася, что ему интересно, и связать свое задание с этим интересом. Такая гибкость ума и чуткость воистину достойна уважения.
Так о чем эта задача? И какое отношение она имеет к реальной жизни? Ведь бред же сивой кобылы – просить программистов ямы копать. Тем более, не имея на это внутреннего морального права.
Теперь представьте, что вы приходите к программисту, вам срочно надо кнопку на сайте перекрасить. Из красной в зеленую. Потому что клиент рвет и мечет (мантры, вроде «URGENT! IMPORTANT! ВЫ НЕ КЛИЕНТООРИЕНТИРОВАННЫЕ» и т. д.). Никак свою задачу не мотивируя. Клиент имеет, наверное, право ничего не объяснять за свои деньги, но это не точно.
А программист Вася вместо того, чтобы за две минуты поправить CSS-файлик, да еще и варианты вам показать с экрана в Developer Tools, начинает артачиться: «Не-хо-чу! Дизайн – это дело не программистское! Вот принесете мне отрисованный макет, утвержденный клиентом, я и поправлю. А то уже пять раз за день туда-сюда-обратно. Достали, менеджеры, блин, работать спокойно не дают».
И в чем-то есть его правда. Но для вас он ведет себя как говнюк. А отфутболить неопытного руководителя проектов фразами «задача не моя» или «предоставьте мне то, это, и еще вон-то, поменяйте кресло, поставьте новый комп и монитор побольше, сделайте нормальные постановки, и тогда я, может быть, соизволю что-то там запрограммировать» – Вася может практически по любому поводу, по любой задаче. С этим все сталкиваются. Мне особенно везло на специалистов 1С на стороне клиентов, на которых смотрят как на священную корову. А если он, ко всему, по совместительству родственник директора, заставить сделать его что-то полезное для проекта, да еще и в срок – тот еще квест.
Ключевых вопроса тут два:
1. Где та грань, когда вы требуете от программиста какого-то бреда (вроде выкапывания ямы), а где он просто говнится, чтобы вы отстали?
2. На что опираться руководителю проекта, чтобы добиться нужного ему результата?
Начнем со второго вопроса. Требовательности.
2.2. Требовательность
Требовательность – базовое качество руководителя, в том числе – и руководителя digital-проектов. Это умение настоять на своем, отстоять интересы компании, команды, проекта и свои, если на эти интересы покушается вселенная.
В идеале управление digital-проектом сводится к расстановке приоритетов: это делаем в первую очередь, это – во вторую. Команда весело разбирает тикеты и дружно бежит их выполнять. Желательно автономно: сами подумали, сами быстро и качественно сделали. Вас же на всякую фигню не отвлекают. А только радуют результатами.
Размечтался. Гораздо чаще можно встретить сопротивление требованиям, затупы, а иногда – скрытый или даже явный саботаж.
Требовательность плотно связана с понятиями «власть» и «эксплуатация». Про источники власти много любопытного у Макиавелли, Ницше и других великих умов мира сего. Власть божественная или государственная, бла-бла-бла… – нам так круто не надо. Для управления digital-проектами интересна власть, которая устанавливается внутри команды проекта и разделяет людей на тех, кто командует, и тех, кто подчиняется.
Требовательность – токсична, и в больших количествах – яд (вплоть до психосоматики). Давят сроки, обстоятельства, клиенты, объем параллельных проектов. И малейшее сопротивление требованиям или уточняющий вопрос команды исполнителей вызывает у перегруженного руководителя раздражение. Оставаться при этом еще и в позитивном настроении – сложно.
