Утопия или несколько мыслей как сделать нашу жизнь лучше…

В Росси две беды. И если одну можно решить с помощью дорожного катка, то что делать с дорогами – ума не приложу…

В общем, так – задолбало. Дороги делают, все перекопают, потом бросят, перекопают в другом месте. Когда все уже забыли, вернутся. Что-то еще поделают – и опять бросят. Или, вроде, сделают дорогу, а по сторонам и мусор и старые бордюры и еще не пойми что – оставят. И разметка. Такое впечатление, что разметка – это не часть дороги. А освещение, а прилегающие территории, а тротуары и, прости господи, велодорожки. А газоны с зелеными насаждениями.

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

И так для всех видов и типов дорог, включая подъездную дорогу к дому и придомовые дороги и тротуары.

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

Итак, утопия: У наших чиновников есть деньги на ремонт дороги. Они публично проводят выбор объекта из списка. Список в свободном доступе – каждый может проголосовать за или против. Потом объявляют конкурс. Там сказано – провести работы на таком-то объекте. Тип объекта такой-то. Все. От типа объекта зависит что нужно сделать, в какие сроки, кто имеет право эти работы производить и, самое утопичное, сколько эти работы стоят. Победитель конкурса приступает к работам и в рамках регламента для данного типа работ все исполняет. После этого на объект выезжает независимая экспертиза, которая состоит из представителя от транспортного сообщества, представителя общества зеленых или синих или любых других цветов, еще какой-то народец. Берут они чеклист приемки объекта такого-то типа. И по этому чеклисту все проверяют. Кстати – чеклист в свободном доступе, любой может ознакомиться и проверить. Готовят отчет. Если замечаний нет – объект принимается, и переходит в режим гарантии на тот период, который предусмотрен для объектов данного типа. Например – на 20 лет. Если замечания есть – исполнитель их устраняет в сроки, предусмотренные для объектов данного типа. А если не исполняет – у этого исполнителя слетает ранг или уровень. Короче – он теряет право выполнять работы данного типа. В общем, я же сказал – утопия.

Проблема в том, что это утопия для отдельно взятого куска суши, где-то в размере 1/6 от всей доступной для проживания. На остальных 5/6 – это скорее норма. Например, вышеописанная схема почти полностью списана с Чехии. В Америке примерно так же. Кстати, в Америке стоимость 1 км хайвея, вне зависимости от штата, стоит $1 млн. Причем, без разницы – новый участок или ремонт. Вроде, дорого. А вот и нет. Дело в том, что в России ничего и близко нет похожего на те хайвеи. Оно и понятно, нам оно не надо. А все таки – хорошая идея. Хайвей – это такая дорога федерального уровня, которая проходит через все штаты, города и веси и нигде не имеет светофоров, пешеходных переходов и перекрестков, кроме съездов справа и выездов, тоже справа. Иногда, правда, бывают съезды слева – но это только в крупных городах и об этом тебя огромные плакаты за милю предупреждают. У хайвея может быть от двух рядов в одном направлении до, например, 6-7 или даже 10 в случае развязок. Слева и справа от этих рядов всегда идут технические зоны, которые выделены специальным ребристым перфорированием бетона (если по нему ехать – будет тыц-тыц-тыц-тыц) – для проезда спецтранспорта в случае заторов и пробок. И всегда противоположные направления жестко разделены – либо забором, либо газоном, иногда каналом. И вот представьте – несколько хайвеев пересекаются в каком-нибудь Майами. Незабываемая картинка (скачал с инета).

Кстати, а знаете сколько стоит один километр МКАДа? Это самый близкий к хайвею объект. Интернет вам в помощь. Причем, МКАД еще не самый дорогой объект. А ведь дороги строятся за налоги. За наши с вами деньги. Может, пора начинать спрашивать куда и как тратят наши с вами деньги те, кто к ним, по теории, никакого отношения иметь не должен. Да, да, я же сказал – утопия…

Маргарет Тэтчер любила рассказывать такую историю:

Когда ваш ребёнок заработает свои первые деньги на мороженое, то сделайте следующее:
1. Перед тем, как он успеет лизнуть своё мороженое, выхватите его у него и откусите 20%.
2. Пока ребёнок будет с изумлением таращится на вас, откусите ещё 30%.
После этого отдайте ему остаток мороженого и объясните, что так государство поступает со всеми деньгами, которые кто-то зарабатывает. И что так будет с каждым мороженым, которое он себе купит. И что % откусываемого можно сократить, схватив откусывающего за руку и потребовав отчёта, почему он откусывает именно столько.
Если так будет делать каждый родитель, есть надежда, что в стране вырастет поколение людей, которые поймут, что у государства нет своих денег – есть только деньги налогоплательщиков.
И что налогоплательщики не просто могут, но и должны следить за тем, как государственные чиновники расходуют их деньги.

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

Всем добра.

Севастополь, 2020

ITC Solutions

Денис Тимофеев, CEO

Выученные уроки одного PM

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

Инициатива презентации вышеупомянутых практик (или Lessons Learned) исходила от менеджмента компании и решала вполне конкретные цели. Неоспорима важность извлечения уроков и для команды, и для проекта в целом. Помимо получения однозначного ответа на вопрос “чему мы научились?”, нам также становятся понятны зоны роста и видение будущего проекта. Такие мероприятия важны и для всей компании, ведь внутренний обмен опытом представляет большую ценность, прежде всего из-за своей доступности. В этой статье я опишу первое подобное мероприятие в нашей компании и постараюсь подтвердить выдвинутые мною тезисы о полезности такой практики.

Итак, зафиксируем точки сравнения. На начало проекта в команду входили 2 бизнес-аналитика (они же разработчики, именуемые так ввиду особенностей инструментов разработки) и управляющий проектом; работа строилась на Kanban доске с элементами Scrum (нечеткий бэклог, нерегулярные планирования, про ретро молчу, однако работа делилась на спринты и какие-никакие демо все же проводились). Сразу отмечу, что на тот момент такая организация была отчасти оправдана, т.к. по коммерческим причинам не было четкой уверенности, и целью было как можно быстрее показать хоть что-то. Со временем, уверенность в продукте появилась, и на сегодняшний день в команду проекта входят Project manager, 3 бизнес-аналитика, 1,5 QA (проекту выделен отдельный QA-инженер, а также QA lead с частичной занятостью), .NET-разработчик; по рабочему процессу можно сказать, что проект полностью работает по методологии Scrum. В рамках нашего первого мероприятия я выделил 6 основных выученных уроков, о которых изложу ниже.

1-й урок – Внедрение Scrum poker. Это распространенная практика, позволяющая команде быть уверенной, что все оценки будут обоснованны, т.к. без консенсуса не будет принята ни одна оценка. Мы начали каждое наше планирование проводить с покером. Работая в офисе, мы использовали напечатанные карты (4 оценки в story points + 4 дополнительные: «?», «∞», «0», «☕»). Перейдя, в свете известных событий, на удаленную работу, мы начали использовать открытый онлайн ресурс PointingPoker.Com. Нам он подошел прежде всего тем, что позволяет настраивать номиналы карт вручную. Хочу отметить, что раньше планирование у нас сводилось к бесконечным обсуждениям, наши мнения часто не соответствовали друг другу, и чувствовалось «доминирование» одного мнения. В результате, мы планируемся с покером более 2-х месяцев и имеем: схождение в 90% случаев запланированных и реальных оценок; а также уверенность, что взятые в спринт задачи реализуем в срок.

2-й урок – Внутренние демо для QA. Постепенно улучшая Scrum процессы, мы искали полезный формат проведения внутренних демо, и нашли его в проведении демо для QA инженеров. Имея 2-х недельные спринты, каждый 2-й понедельник Project manager и инженер QA, закрепленный за проектом, проводят встречу, на которой происходит разбор нового и обновленного функционала. Основная цель – обновить заведенные тест-кейсы и подготовить тест-план к регрессионному тестированию. И это действительно помогло. Раньше согласования тест-кейсов были устные, и мы нередко сталкивались с несоответствием понимания задач у бизнес-аналитиков, и у QA инженеров. В совокупности это позволило нам снизить (примерно на 50%) время вхождения QA в понимание, что тестировать; а также мы перестали получать вопросы «ошибка или нет?» и пр., которые неминуемо появлялись раньше.

3-й урок – Отчеты клиентам по обновлениям. После каждого планового обновления, а они на проекте, напомню, раз в 2 недели, была заведена привычка формировать текстовый отчет и предоставлять его клиенту, с описанием новых функциональных возможностей. Таким образом, я, как PM, формирую такой отчет на основе Release notes спринта, и отправляю его клиентам после обновления. До этого показ нового функционала мы проводили только на демо, причем было это нерегулярно; а по сему мы сталкивались с вопросами «как должно работать?». Итог понятен и краток – снижен уровень недопонимания у клиента по переданному функционалу в релизе.

4-й урок – Понятная работа с требованиями. Ввиду особенностей работы на проекте требования от заказчиков поступают постоянно, и мы этому рады. В рамках этого пункта была выстроена понятная схема работы с запрошенным функционалом. Изначально PM фиксирует требования совместно с менеджерами клиента; после – РМ подготавливает концепцию реализации функциональности; концепция просматривается менеджерами клиента и отправляется функциональным заказчикам на рассмотрение; после этого происходит аналитика, расчет трудозатрат, реализация. До этого требования мы и получали, и обрабатывали хаотично. Присутствовали долгие обсуждения без конкретики, и в последний момент (когда бэклог становился пустым) резко активизировалась работа и проходили срочные согласования. В результате, на сегодня мы имеем согласованный функционал и понятный план проекта более чем на 2 месяца, а также ведем активные согласования большого III-го этапа разработки (используя эту самую схему).

5-й урок – Критерии Ready to release. Наш проект (на ряду с еще одним проектом в компании) начал работать с критериями готовности к релизу, которые обеспечивают QA инженеры. После каждого регрессионного тестирования они формируют отчет по нему, куда включают соответствующие критерии. Отчет также направляется и клиенту. До принятия критериев релиз происходит по моей субъективной оценке, причем полной уверенности в релизе не было (т.к. отсутствовали параметры оценки). Теперь можно сказать, что мы имеем единое (на 100%) понимание готовности к релизу и у нас, и у клиента; также повысилась вовлеченность клиента в процессы разработки и уверенность в продукте.

6-й урок – Учет «подушки» при планировании. Речь идет об учете 20% запаса трудозатрат при планировании спринта, на случай непредвиденных затрат (блокеры, хотфиксы и пр.). Так, при планировании спринта мы на каждого исполнителя набираем трудозатрат на 20% меньше, чем брали ранее, т.е. от рассчитанного количества (расчет производится по количеству рабочих дней). Ранее мы часто сталкивались с несоответствием фактических и планируемых трудозатрат, в результате появлялись просроченные трудозатраты. На сегодняшний день можно сказать, что на 75% уменьшены опоздания к деплоям на тест (перед началом регрессионного тестирования), а также сведен к 0 риск несвоевременного релиза клиенту.

В итоге хочется отметить, что уроки, которые мы извлекли за полгода работы на проекте, позволили нам значительно улучшить качество и процесс работы. Из основных результатов можно отметить, что за весь период по сегодняшний день мы в полной мере внедрили на проект Scrum; за последние 4 месяца ни разу не выбились из графика релизов; возросла роль коммуникаций с клиентами; а также постоянно согласуются новые требования, что дает уверенность в светлом будущем проекта.

Севастополь, 2020

ITC Solutions
Evgenii Chuprynin, PM