Попса

популярный светский альманах

О том, как правильно писать дефекты.

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

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

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

Заголовок

Заголовок должен отвечать на вопросы: «Что? Где? Когда?». Суть ошибки, локализация и условия, при которых она возникает. Например: «Сбрасывается галка менеджмента в редакторе сметы при сохранении»
 
 
 

Описание

Описание должно отвечать на вопросы: «Что делал? Что получилось? Что должно было получиться?»

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

  1. Создаю и открываю на редактирование смету.
  2. Ввожу перечень работ.
  3. Ставлю галку менеджмента и прописываю значение.
  4. Сохраняю смету

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

 
 
 

Аттач

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

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

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

Приоритет

  • Blocker – проблема блокирует функционал.
  • High – серьезные проблемы функционала, задевающие основной сценарий/главные фичи, которые нужно исправить в первую очередь.
  • Normal – стандартные баги функционала/ верстки.
  • Low – опечатки, мелкие баги верстки.
    Баг желательно вешать на разработчика, ответственного за кусок функционала, затронутый багом.
  •  
     
     

    Окружение

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

 
 
 

Распространённые ошибки

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

Скриншот вместо фактического результата. Формулировка вида «Ничего не работает» и скрин в аттаче, вот и весь дефект. За такие дефекты надо отрывать руки. В 99 % случаев проблему можно описать способом, о котором я рассказал выше и дефекты такого типа — следствие лени проверяющего.

Невнятные шаги воспроизведения. Всегда нужно помнить первую татуировку из книги «45 татуировок менеджера»: То, что очевидно для вас, неочевидно для остальных. Если описать шаги недостаточно подробно, есть риск, что разработчик просто не сумеет воспроизвести баг и вернёт его на доработку, что приведёт к потере времени.

Постановка всем багам высшего приоритета. Тут как с мальчиком, который кричал «Волки!» Если всем багам ставить высший приоритет, отношение к ним будет одинаковым — исправляем по мере возможности. Высший приоритет следует приберечь для действительно серьёзных проблем, которые прямо сейчас блокируют работу большому количеству пользователей.

Blisk — браузер с эмуляцией мобильных устройств

Blisk — браузер с эмуляцией мобильных устройств

Хочу поделиться новым рабочим инструментом. Это браузер для разработчиков под названием Blisk. Браузер сделан на движке Chromium и на нём пашут все нужные расширения хрома (вы можете видеть на скриншоте LastPass и Screencastify).

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

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

Кроме того, браузер имеет встроенный инструмент для записи скриншотов и скринкастов с выкладыванием в собственное облако. К сожалению, за использование облака придётся заплатить 10 $ за пользователя (оптом скидки).

Краткий гайд по айтишным профессиям

Профориентация

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

 
 
 

Менеджер проектов

Обязанности

  • Ведение переговоров с заказчиком. Сбор требований. Часто — написание технического задания (в некоторых компаниях этим занимаются бизнес-аналитики)
  • Оценка стоимости и продолжительности работ с командой проекта.
  • Планирование работ. Составление календарных планов, определение дедлайнов.
  • Приёмочное тестирование, оценка, правильно ли разработчики выполнили задачу.
  • Проведение стендапов с командой, оперативное планирование.
  • Консультирование команды по ТЗ, разруливание сложных и противоречивых случаев.

 

Каким людям подходит

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

 

Как им стать

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

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

 

Подводные камни

Подводные камни состоят в том, что для того, чтобы объективно оценить качество работа ПМ-а, требуется, минимум, полгода, а продолжительность испытательного срока обычно не превышает 2-3 месяцев. Из-за этого работодатель оценивает кандидата субъективно, на уровне «нравится-не нравится».

 

Уровень зарплат

Уровень зарплат — 30-50 тыс. руб. при наличии минимального опыта в регионах и 80-100 тыс. руб. в Москве или Питере. Без опыта устроиться практически нереально, поэтому обычно будущие ПМ-ы работают на должность аналитиков или разработчиков и постепенно вырастают в своей организации до ПМ-ов.
 
 
 

Менеджер продукта

Обязанности

  • Разработка новых продуктов и их продвижение;
  • Управление ассортиментом; (продуктовой линейкой вендора)
  • Планирование KPI продукта на краткосрочной и долгосрочной основе, мониторинг исполнения KPI;
  • Ценообразование;
  • Прогнозирование продаж;
  • Ведение аналитических данных по конкурентам;
  • Исследования рынка и отрасли, анализ тенденций развития, анализ конкуренции;
  • Создание программ по стимулированию продаж;
  • Подготовка маркетинговых материалов;
  • Подготовка и проведение презентаций;
  • Написание и публикация материалов по продукту;
  • Консультирование партнеров по техническим вопросам;
  • Участие в переговорах с клиентами;

 

Каким людям подходит

Требуется развитый абстрактный интеллект.

 

Как им стать

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

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

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

 

Подводные камни

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

 

Уровень зарплат

40-50 тыс. руб в регионах, 100-150 тыс руб. в Москве и Питере. Без опыта устроиться практически невозможно, требуют портфолио проектов/продуктов.
 
 
 

Аналитик

Обязанности

  • Переговоры с заказчиком, сбор, анализ и документирование требований.
  • Написание технического задания.
  • Управление требованиями.
  • Консультация команды по вопросам ТЗ, поддержание ТЗ в актуальном состоянии.

 

Каким людям подходит

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

 

Как им стать

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

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

 

Подводные камни

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

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

 

Уровень зарплат

25-40 тыс. руб в регионах, 60-80 тыс. руб. в Москве и Питере. Конкуренция не очень высокая, есть шанс устроиться с минимальным релевантным опытом.
 
 
 

Технический писатель

Обязанности

  • Написание руководств пользователя.
  • Иногда — написание ТЗ под диктовку ПМ-а или бизнес-аналитика.
  • В компаниях, работающих на господрядах — написание документации, требующейся по ГОСТу.

 

Каким людям подходит

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

 

Как им стать

Можно устроиться без опыта, главное — умение грамотно писать по-русски без ошибок. Также нужно уметь пользоваться несложной разметкой Media Wiki и управляться с Confluence.

Для работы с окологосудаственными компаниями, требуется знание ГОСТ 34.

 

Подводные камни

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

 

Уровень зарплат

25-30 тыс. руб. в регионах, 40-50 тыс. руб. в Москве и Питере.
 
 
 

Тестировщик

Обязанности

Тестировщики делятся по специализации на специалистов по ручному и автоматизированному тестированию.

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

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

 

Каким людям подходит

Требуется развитый абстрактный и вербальный интеллект.

 

Как им стать

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

В автоматизаторы можно вырасти из ручного тестировщика, приобретя нужные компетенции.

 

Подводные камни

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

 

Уровень зарплат

20-30 тыс. руб. в регионах, 40-80 тыс. руб. для Москвы и Питера.
 
 
 

Разработчик

Обязанности

  • Реализация приложений, согласно ТЗ.
  • Оценка трудоёмкости и сроков разработки.
  • Иногда — написание модульных тестов.

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

 

Каким людям подходит

Требуется развитый пространственный и абстрактный интеллект. Требований к вербальному и эмоциональному практически нет.

 

Как им стать

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

 

Подводные камни

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

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

 

Уровень зарплат

30-120 тыс руб. в регионах, 60-200 тыс руб. в Москве и Питере. Программисты с редкими и сложными специализациями могут получать значительно больше. Вообще, уровень зарплат выше, чем у всех остальных ролей, что делает работу программиста очень привлекательной в карьерном плане.
 
 
 

Дизайнер

Обязанности

  • Отрисовка интерфейсов по ТЗ.
  • Продумывание логики интерфейсов вместе с аналитиком и ПМ-ом.

 

Каким людям подходит

Требуется развитый абстрактный и ВНЕЗАПНО вербальный интеллект — дизайн нужно презентовывать самостоятельно и уметь обосновывать и отстаивать свои решения.

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

 

Как им стать

Дизайнером можно устроиться без опыта, имея за плечами профильное образование или портфолио самостоятельно нарисованных интерфейсов.

 

Подводные камни

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

 

Уровень зарплат

20-40 тыс. руб. в регионах и 60-80 тыс. руб. в Москве и Питере.

О планировании загрузки команды

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

Начнём с того, что всех пользователей можно разбить на команды. iOS, Android, QA, дизайнеры и так далее, а потом фильтровать по этим командам доску. В верхней части доски можно для наглядности ставить вехи ключевых событий, которые должны в этот день произойти. В основном поле, в строках участников, рисуются «колбаски» загрузки. Есть возможность выбрать из списка проект, написать название работы, количество часов в день и сроки. Каждому участнику можно написать количество рабочих часов. Если в данный день загрузка неполная, в верхней части строки отображается количество недогруженных часов.

Сервис можно интегрировать со Slack, Button, Trello, Basekamp и GitHub. Кроме того, он умеет слать письма исполнителям о том, что на них назначена активность. Формировать загрузку команды при помощи этого сервиса намного удобнее, чем в гуглотаблицах.

Об очередях задач

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

О контроле

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

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

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

О том, как устроить свою работу так, чтобы было интересно

Очень интересный рассказ Людвига Быстроновского о том, как устроить работу так, чтобы было интересно.

Запомнилась мысль. Нужно попробовать мыслить иррационально, не логически. Например, повару вместо того, чтобы выпустить очередной сборник рецептов, написать книгу «300 способов испортить еду». Абсолютно нелогично и иррационально, и такую книгу будет хотеться взять с полки и купить. Как это — 300 способов испортить еду. Я знаю три — переморозить, пересолить и пережарить. Интересно, какие ещё 297.

Так вот, худшее, что может сделать повар после выпуска такой книги — выпустить книгу «300 способов испортить напитки».

О делегировании

Делегирование

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

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

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

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

О потоковом рекрутинге

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

По ссылке карта в pdf и mmap.

О фиксации изменений

pexels-photo

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

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

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

Для фиксации изменений требуются два артефакта — реестр изменений (особенно критичен для больших проектов) и карточка изменения.

Карточка изменения

  • Название проекта
  • Дата актуализации
  • Текущий статус
  • Описание изменения
  • Причина изменения
  • Влияние изменения
  • Резолюция заказчика
  • Резолюция исполнителя

Шаблон

 

Реестр изменений

  • Название проекта
  • Дата актуализации
  • Описание изменения
  • Инициатор изменения
  • Статус изменения
  • Дата получения информации

Шаблон