Попса

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

Категория: Разработка

О том, как сделать узкоспециализированную задачу в приемлемые сроки.

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

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

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

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

Пять признаков проекта, который провалится

Пять признаков проектов, которые провалятся

Подавляющее большинство проектов проваливается. Понять, что данный проект провалится, не очень сложно. Есть несколько маячков.

Дедлайн спущен сверху

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

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

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

Я делал такие проекты. Приходилось подключать дополнительные ресурсы, максимально упрощать фичи, экономить на качестве. Как правило, это приводило к тому, что проект был либо сдан вовремя, либо с небольшим опозданием, однако пользоваться продуктом было невозможно из-за багов и наступали «вторые 90 % проекта», когда попеременно наши тестировщики и приёмщики заказчика шлют баги, а разработчики их мужественно правят.

В общем, если дедлайн спускается сверху без точных расчётов, проект, скорее всего, провалится.

Планируют и реализуют разные люди или даже подразделения

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

В отличие от материального труда, где производительность сотрудников различной квалификации примерно сравнима (нельзя, например, нанять сениора плиточника, чтобы он за ночь обложил вам плиткой большую ванную комнату, если реально там труда на несколько дней) и сотрудники относительно взаимозаменяемы, в разработке так нельзя. Сениор может кодить быстрее мидла не в два, не в четыре раза, а на порядок. Да ещё и допускать в коде меньше дефектов. И специалисты примерно одной квалификации могут сильно различаться по производительности.

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

Руководитель проекта недостаточно квалифицирован или мотивирован

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

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

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

Не определились с особенностями реализации проекта

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

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

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

Не определены специфические критерии успешности проекта

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

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

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

О Full Stack разработчиках

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

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

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

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

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

Заголовок

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

Описание

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

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

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

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

 
 
 

Аттач

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

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

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

Приоритет

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

    Окружение

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

 
 
 

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

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

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

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

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

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

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

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

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

pexels-photo

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

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

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

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

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

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

Шаблон

 

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

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

Шаблон

Об адаптации новых сотрудников

Новичок

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

В одной компании дело дошло до маразма — по должности мне было положено принимать дизайн, но монитор выдали ЭЛТ-шный (нет, не профессиональный ЭЛТ-шный, а пятнадцатидюймовый гробик 1024 на 768, на котором невозможно нормально откалибровать цвета). Пришлось потратить массу времени на убеждение сисадмина, затем своего начальника. Кстати, это не помогло, монитор заменили только после вмешательства генерального.

Суть адаптации нового сотрудника — сделать два чек-листа.

В первом написать, что нужно сделать до прихода сотрудника (вытереть стол от пыли, поставить оборудование в соответствии с должностью, подготовить бумаги для оформления, сделать пропуск и так далее)

Во втором написать, что нужно сделать после прихода сотрудника (рассказать, во сколько приходить, когда обед, когда уходить, можно ли работать из дома, выдать зарплатную карту, показать, где наливать кофе и куда выбрасывать мусор и так далее).

Затем нужно лишь применять эти два чек-листа к каждому новому сотруднику.

Ещё можно сделать страницу «Информация для нового сотрудника» в корпоративной вики, если такая у вас имеется.

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

Fallout 4

fallout 4

По слухам, сюжет будет построен вокруг конфликтов бостонских группировок — «Института», Братства Стали, Железнодорожников из Убежища 79 и разных мелких банд.

Главным героем будет мужчина без возможности выбрать пол — такова особенность сюжета. Предполагается, что протагонист с женой и ребёнком застанут ядерную атаку, скроются в убежище 111, где их закриогенят на столетия. Интересный момент. Главгерой по прозвищу «Офицер» будет полностью озвучен, впервые не только за всю серию Fallout, но и вообще, всех игр Bethesda.

Дата выхода игры пока неизвестна, но велика вероятность, что релиз состоится в этом году на PC, PS4 и Xbox One, также возможен выход версий для старых приставок PS3 и Xbox 360.

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

Pillars of Eternity

Pillars of Eternity

Второй день гоняю в Pillars of Eternity. Это такой отход к традициям классических RPG — изометрический вид, много-много диалогов, куча рас и классов, немеряно параметров и навыков, причём каждое вложенное очко влияет на геймплей.

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

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

Забытый стиль боя «дверной ниндзя». Первый и второй танк по бокам от двери, справа медведь, в метре от танков варвар, на задней линии жрец и маг. Хантер идёт вперёд и из невидимости агрит противника калечащим выстрелом. Тактическая пауза, жрец произносит поддерживающее заклинание, первый танк готовит повышение меткости, второй — какую-то паладинскую приколюху, варвар входит в боевое безумие. Хантер драпает назад, пробегает через дверь, становится рядом с магом, варвар делает шаг вперёд и смыкает строй у дверей. Жрец кидает шестисекундное молчание на мага противника, наш маг дезориентирует воина противника, добежавший хантер оставшимися калечащими выстрелами мочит вражеских лучников…

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

Двумя постами ниже я жаловался, что в боевике COD нет возможности выбора. В этой игре большая часть квестов содержит дилемму с отсутствием единственного правильного ответа. Исполнить данное в начале квеста обещание убить лорда Редрика и отдать регион под контроль его младшему брату? Но в подвале замка Редрика сидит тётка-анимансер, занимающаяся очень важным исследованием, младший брат Редрика такое не одобряет. Может, нарушить обещание и наоборот, за хорошую сумму помочь Редрику избавиться от братишки? Можно поступить как угодно.

А ещё, можно делать противоречивых персонажей. Магов с двуручниками, умных варваров и подлых паладинов.

В общем, у этой игры не просто так девять баллов от Игромании.

Scrum и Kanban