Вместо «Вот тут проблема» можно написать: «В тексте ссылки на отзыв – абракадабра». Гордый собой менеджер или заказчик считает, что на этом его миссия по формулированию проблемы – заметьте, четкому формулированию – закончена. Мол, вот баг, вот скрин, описание – смотри на скрине. Но так не пойдет: если таких багов двадцать (или двести), баг-лист превращается в мешанину, и как что искать в таком случае, неясно.
Сейчас за кадром оставим вопрос, почему у вас заказчик нашел баги, и их так много, но акцент не на этом. Это могут быть и формулировки заданий – разницы нет.
Если в таком виде с вами работает ваш клиент, и у вас не получается договориться о нормальных формулировках (ему тоже не до формулирования и четкости и проще вам заплатить побольше денег, чтобы вы сами все фиксировали с его слов), тогда проблем нет. Фиксируйте все сами, сами переводите с клиентского на программистский. Берите за это деньги. Это воспринимается абсолютно нормально в 80 % случаев и ценится (если вы не сильно косячите). Вы экономите клиенту время – и это тоже часть менеджерской работы. К исполнителям формулировки должны попадать такие, чтобы задачу можно было найти поиском. Очевидная вещь, но приходится и про такое рассказывать.
Формулировки стоит писать так, чтобы по ним было легко найти, где случился и как проявился баг. Подробно описывайте, что заставило баг вылезти. И поменьше оценочных формулировок: что это за «абракадабра в тексте ссылки»? В том же Битриксе, например, по умолчанию не генерируются ссылки с человеко-понятными названиями, любой программист вам скажет про это. И даже не попытается понять вашу проблему. Мол, в коробочной версии это работает именно так, чего вы от меня хотите?! Это нормальное поведение программистов – и нельзя их за него осуждать.
Бывают формулировки, из которых непонятно: это проблема или требование? Пример – «ссылка фиолетовая». И что? Она должна такой быть или ошибка в том, что она фиолетовая, а должна быть серой? Дело в том, что непонятно, что именно вы хотите, чтобы с этим фактом сделали и как именно его поправили.
Другая частая ошибка менеджеров – формулировки задач в виде пожеланий. С оговорками «мне кажется», «я думаю», «а как на ваш вкус» и так далее. Опять же, если такие формулировки приходят от клиента – нормально, если менеджер их уточняет и конкретизирует. Слово «кажется» – это из словаря терминов-паразитов. В баг-листах, в формулировках задач прилагательные и местоимения – это слова, которые можно трактовать двояко. «Каждый», «любой», «все», «больше», «меньше» и так далее. Это признак нечеткой постановки. Как минимум – перепроверьте, можно ли такие слова перевести в четкие цифры или конкретизировать (не всегда, но можно).
Еще одна дичь – эмоциональность (или даже скрытая пассивная агрессия) в постановках, чатах или рабочих артефактах. Ниже – пара примеров из практики: правильно-неправильно и пара примеров на «подумать», как могло бы быть правильно, а главное – чтобы поставить себя на место того человека, который получил задачу или обратную связь о своей работе в таком виде:
Представьте, что программист переживает расставание с подружкой, пришел с плохим настроением. Открывает текстовый редактор. Создает файл VsePloho.php. В нем – класс PolniyPipec. А в нем метод KakViVseDostali (vi, vse). На другой день настроение наладилось, помирились, новый файл уже SuperPuperMegaKorzina.php и все в таком роде. И это все идет на ревью службе безопасности. Думаю, там разговор будет короткий.
Организуйте постановки по принципу «пирамиды». Заголовок задачи должен быть такой, чтобы была понятна суть и не приходилось много читать. Детали помещайте в описание.
В баг-листах, помимо описания проблемы, ее места на сайте и способов воспроизвести баг, также указывается приоритет. В разных компаниях системы приоритетов обычно складываются исторически. У нас она – вот такая:
▶ 0 – критические баги (падает сервер или не работает оплата), нулевой приоритет ставим в случае, если тестировщик из-за этого бага не может дальше продолжать проверку проекта.
▶ 1 – либо что-то забыли реализовать, либо что-то критичное по юзабилити.
▶ 2, 3 – менее критичные вещи.
▶ 4 – ошибки в текстах или текстовые правки.
▶ 8 – это «хотелки», некритичные баги.
Замечу, что это именно наши приоритеты по разработке. Например, у рейтингового агентства «Тэглайн» приоритеты другие: для них ошибка в продающем тексте может быть более приоритетна, чем криво работающая форма подачи какой-нибудь анкеты. Ну, ради бога.
Мы намеренно пропускаем 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 пассажир и пилот сидят бок о бок, ситуацию удалось мгновенно исправить.
Ты можешь сделать круто на своем проекте глобальные вещи. Но мелочи – это то, что может погубить твой проект. Обращай внимание на каждую деталь, какой бы мелкой и незначительной она ни казалась. Мелочи – это то, что может стать большой проблемой, если вовремя на них не отреагировать.
Я очень избирательно отношусь к пассажирам-покатушникам на борту и очень тщательно их инструктирую. Вряд ли возьму незнакомого или показавшегося хоть в чем-то неадекватным человека.
Был случай, когда на взлете испугавшийся (или от эйфории) пассажир попытался перехватить у меня управление. Благо в RV-7 он сидел рядом, и можно было успокоить пассажира. В самолетах типа Extra, Як-52 или Су-29, где кабины разделены и посадка друг-за-другом – такой возможности нет.
Ребята рассказывали про ситуации, когда испуганная девушка-пассажир крепко зажимала сильными ногами ручку управления самолетом и на призывы: «Расслабься. Расслабь ноги. Ноги расслабь! РАЗДВИНЬ НОГИ $%^^…!!!» – реагировала слабо.
Кто у тебя будет на проекте, и как он себя поведет – от этого во многом зависит будущее твоего проекта. В идеале, у тебя должна быть возможность менять членов команды, особенно если ты головой отвечаешь за результат.
Да, есть куча всяких контролирующих органов, транспортной прокуратуры, проверок, центров сертификации, подач планов, диспетчеров, техников, метеорологов, и всякого такого. Но как только ты – КВС (командир воздушного судна) и принимаешь решение о взлете – ВСЯ (ВСЯ!) ответственность на тебе. Отмазки не канают. Никакие.
Ты управляешь проектом (или компанией) и позволяешь себе оправдания, типа «ой, я тут всего лишь не посмотрел/не подумал», или любишь переваливать ответственность на внешние обстоятельства, сложного заказчика или рукожопых исполнителей? Сорян, тогда рано тебе еще этим заниматься.
Брать на себя всю ответственность – это, кстати, прикольное чувство, попробуй.
Чем больше ты летаешь – тем больше будет разных ситуаций.
Вот недавно знакомые летчики в районе Телецкого озера попали в облако саранчи. Одно зеленое насекомое попало в ПВД – приемник воздушного давления, который обеспечивает определение скорости относительно воздуха. Итог – отказал указатель скорости.
Скорость – наша жизнь. В горах – особенно интересно. Но ничего, сориентировались. Дошли до ближайшего аэродрома, выдерживая скорость по GPS, а изменение маршрута объяснили «санитарной необходимостью» (хорошая формулировка, емкая!).
Лучше летать много, чем 1–2 раза в год. Пожалуй, пару раз в год – это самое опасное. Либо не летай, либо летай постоянно. Да, вероятность попасть в веселую ситуацию – выше, но и опыт здесь – бесценный помощник.
То же и про управление. Занимаясь чем-то профессионально – нельзя делать это время от времени.
Так уж получилось, что Су-29, который пригнали из-за границы, два года пылился в ангаре. Самолет сложный, суровый. Летать на нем стало некому, однако с учителями везло. Познакомился с Михаилом Переверзевым, мастером спорта России международного класса, многократным призером чемпионатов России, Европы и мира… Короче, крутым парнем.
Сколько было скепсиса у него в глазах, когда я обратился к нему с просьбой о тренировках: «На таких самолетах только мастера спорта раньше летать могли, и то не все… Это не учебная машина. Эх, времена!» Тем не менее, желание вновь полетать на пилотажнике пересилило, и Михаил согласился. Каково же было наше с ним удивление, когда на третьем часу тренировок мы поняли, что я готов к самостоятельному вылету. На четвертом часу полетел сам, в сложных метеоусловиях. Самолет очень живой, и я даже на 10 % не освоил его потенциал.
Помогли увидеть ошибки недавно установленные дымы. Когда за тобой дымный след – сразу видно косяки. В кабине газовая камера, жарко, пот разъедает глаза, а солнышко слепит, но ничего: назвался пилотом – терпи и тренируйся.
Учить и тренировать вас никому неинтересно. И уж точно – никто не обязан вами заниматься. Это время, нервы, и в конце концов – риск. Если вдруг вас учат чему-то на работе и в рабочее время (управлению проектами, дизайну, программированию, soft skills), и вам это идет на пользу – относитесь к этому с благодарностью. А не как к само собой разумеющейся херне. В жизни очень сложно найти хороших учителей и уж тем более заинтересовать/убедить их заниматься вами. Большая удача.
Итак, мы посмотрели картину мира digital-проекта, убедились, что для нас там полно работы и посмотрели, как эту работу делегировать (не поубивав друг друга и с возрастающими шансами на успех).
1. Какие еще объекты вы бы добавили в картину мира digital-проекта? Что вы с ними делаете? Как они связаны друг с другом?
2. Понаблюдайте в течение недели на какие операции и сколько вы тратите времени и энергии. Нравится ли вам это делать, или это рутина? Вы обязаны ее делать, или можно ее кому-то делегировать? Составьте план делегирования рутины. Приводите его в действие.
3. В течение недели попробуйте делать постановки четко по SMART, а письменные постановки с использованием принципа «пирамиды». Проверяйте их через сервис glvrd.ru.
Андрей Курпатов, «Красная Таблетка».
Максим Ильяхов, «Пиши, сокращай».
Максим Ильяхов, «Новые правила деловой переписки».
Старое интервью Стива Джобса о командной работе (ссылка спрятана в QR-коде слева).
Тикет-система – система онлайн-постановки и контроля задач.
Тикеты – собственно, задачи.
Бэклог – инструмент Скрама, по-простому – это список всех хотелок проекта, отсортированный в порядке приоритетов.
NDA – Non-disclosure agreement, соглашение о неразглашении: юридический договор, между сторонами с ограничением доступа третьим лицам к каким-либо данным и/или результату работ.
Софт – программное обеспечение, или ПО.
Репозиторий – место, где хранится код и вся информация о его изменениях. Репозитории могут находиться на компьютере разработчика, на компьютерах его коллег и на удаленном сервере.
Гайдлайн – руководство по правильному использованию визуальных элементов на сайте.
Тест-план – документ, где описывается весь объем работ по тестированию проекта: как, что и когда проверять. В идеале, тест-план пишет опытный тестировщик, а выполнить тест-план способна обезьянка с мышкой.
API – описание способов, которыми один сервис или программа может взаимодействовать с другим сервисом, программой или сайтом.
Спринт – временной интервал, обычно в 2–4 недели, в течение которого scrum-команда выполняет заданный объем работы.
Рисерч – (en: research) исследование: поиск и сбор необходимой для выполнения задачи информации, проба новой технологии и так далее.
Ретроспектива – собрание команды проекта, чтобы проанализировать прошедший спринт и создать план улучшений для следующего спринта.
Деплой – развертывание кода сайта на сервере.
Боевой сервер – обычно весь программный код пишется на тестовом сервере в студии, а после переносится на боевой, рабочий, сервер заказчика.
Артефакт – результат какого-то процесса: в разработке – файлы исходного кода или файлы данных, в управлении – поставленные в тикет-системе задачи.
Пересаживание обезьян – когда подчиненные свешивают своих обезьян, свои проблемы на своего босса, а тот покорно их принимает, потому что «без вас никак не разобраться» или «вам нужно подписать», или «давайте подумаем, что можно сделать» (см. «Одноминутный менеджер и обезьяны», Бланшар К., Онкен-мл. У., Берроуз Х.).
Стендап – короткая планерка менеджера с командой проекта на 10–15 минут, где обсуждаются три главных вопроса: что было сделано вчера, что будет делаться сегодня и какие есть проблемы.
Декомпозиция – разбивка большого и неповоротливого проекта по аккуратным и понятным блокам. Об этом подробнее поговорим в главе 5, посвященной декомпозированию.
Скрипт – это последовательность действий, описанных с помощью скриптового языка программирования.
Фреймворк или, по-русски, каркас – программное обеспечение, которое облегчает разработку. С ним код пишется быстрее, а в дальнейшем его проще поддерживать.
Стэк – в разработке: набор инструментов для создания проектов, который включает языки программирования, фреймворки, системы управления базами данных, системы управления контентом (CMS) и прочие используемые технологии.
Бета-тестер – почти настоящий пользователь, который интенсивно использует почти готовую версию продукта/сайта/приложения, чтобы выявить максимальное число ошибок для их последующего устранения перед окончательным выходом (релизом).
Баг – ошибка на сайте, в сервисе или в приложении.
Баг-лист – список всех найденных тестировщиком багов, который используется разработчиками для того, чтобы эти баги пофиксить (отловить и починить).
Класс – шаблон кода, по которому создается какой-то объект.
Код-ревью – процесс ревизии кода одного программиста – другим, более опытным. Цель: улучшить качество кода и обеспечить соблюдение принятых в команде стандартов.
Давайте решим такую задачу (гротескная, но так будет веселее).
Допустим, у вас есть сотрудник, и вам по каким-то причинам нужно, чтобы он выкопал яму. Все необходимые параметры, в рамках разумного, придумайте самостоятельно.
Пока не читайте дальше, потратьте минутку для того, чтобы сформулировать (лучше вслух), как вы будете такую задачу ставить. Я подожду.
Сформулировали? Если вы использовали, например, смарт-подход и умеете развешивать контрольные точки, у вас могло получиться что-то типа: «Вася, нужно выкопать яму 30×30×30 см для захоронения офисного котика. А то он сдох, и нам тут скоро всем будет очень душно. Вон в том углу забора. Сегодня до обеда. Лопату возьми в сарае, вот тебе ключ. Справишься? А есть шанс, что не справишься?»
Теперь усугубим. Допустим, вы руководитель диджитал-проектов, а Вася – программист. Вы произносите похожую мантру (мол, выкопай яму, очень надо). Он смотрит на вас честными глазами. И говорит: «Не-хо-чу!» Ваши действия?
Первая естественная реакция: «Ну что за бред! Почему я должен уговаривать программиста заниматься непрограммистскими делами?» Потом идут попытки:
▶ надавить на Васю трудовыми обязанностями (облом, Вася знает, что его дело – код писать, а не ямы копать);
▶ уболтать на личном уровне: либо по-дружески, либо девушкиными ходами, строя глазки (облом, Вася – интроверт, идеалист и женатик);
▶ подкупить премией или даже напугать штрафами (не прошло, у программистов все нормально с зарплатами, а с угрозами штрафов идите вы знаете куда? – правильно, в трудовую инспекцию);
▶ или сослаться, что это дебильное задание дало вышестоящее руководство (совсем гнилой ход, особенно с точки зрения морали – фу так делать! – и Вася вас раскусит).
Самые чуткие, внимательные и креативные руководители проектов (а таких попадается 5–7 %) отреагируют на Васино «Не-хо-чу!». Попробуют выяснить, чего хочет Вася, что ему интересно, и связать свое задание с этим интересом. Такая гибкость ума и чуткость воистину достойна уважения.
Так о чем эта задача? И какое отношение она имеет к реальной жизни? Ведь бред же сивой кобылы – просить программистов ямы копать. Тем более, не имея на это внутреннего морального права.
Теперь представьте, что вы приходите к программисту, вам срочно надо кнопку на сайте перекрасить. Из красной в зеленую. Потому что клиент рвет и мечет (мантры, вроде «URGENT! IMPORTANT! ВЫ НЕ КЛИЕНТООРИЕНТИРОВАННЫЕ» и т. д.). Никак свою задачу не мотивируя. Клиент имеет, наверное, право ничего не объяснять за свои деньги, но это не точно.
А программист Вася вместо того, чтобы за две минуты поправить CSS-файлик, да еще и варианты вам показать с экрана в Developer Tools, начинает артачиться: «Не-хо-чу! Дизайн – это дело не программистское! Вот принесете мне отрисованный макет, утвержденный клиентом, я и поправлю. А то уже пять раз за день туда-сюда-обратно. Достали, менеджеры, блин, работать спокойно не дают».
И в чем-то есть его правда. Но для вас он ведет себя как говнюк. А отфутболить неопытного руководителя проектов фразами «задача не моя» или «предоставьте мне то, это, и еще вон-то, поменяйте кресло, поставьте новый комп и монитор побольше, сделайте нормальные постановки, и тогда я, может быть, соизволю что-то там запрограммировать» – Вася может практически по любому поводу, по любой задаче. С этим все сталкиваются. Мне особенно везло на специалистов 1С на стороне клиентов, на которых смотрят как на священную корову. А если он, ко всему, по совместительству родственник директора, заставить сделать его что-то полезное для проекта, да еще и в срок – тот еще квест.
Ключевых вопроса тут два:
1. Где та грань, когда вы требуете от программиста какого-то бреда (вроде выкапывания ямы), а где он просто говнится, чтобы вы отстали?
2. На что опираться руководителю проекта, чтобы добиться нужного ему результата?
Начнем со второго вопроса. Требовательности.
Bu va yana 2 ta kitob 399 UZS