Хочу поведать свою историю, как большая нагрузка, множество рутинной работы и постоянное отвлечение меня от основной работы, разработки архитектуры софта, толкнули меня на создание системы, которая бы автоматизировала ряд процессов в пресейле новых проектов. Что позволило мне сэкономить в итоге много времени и сил.
Скажу пару слов о том, чем я занимаюсь. Более 25 лет я занимаюсь разработкой программных продуктов под WEB. Начинал еще в 90х, как разработчик десктопных приложений. Писал, практически на всем. На разных ЯП, CMS, фреймворках. Перепробовал все что только можно. Искал себя и смысл жизни (себя нашел, а смысл жизни — нет). Меня всегда увлекала инженерная и архитектурная часть, поэтому я хотел докопаться до самой сути вещей, уделяя огромное внимание не технологиям и инновациям, а деталям, логике и здравому смыслу. Лет через 10 после старта, я устал от однотипных задач и непонимания, что я делаю и зачем, не имея возможности влиять на конечный продукт. И ушел в архитектуру.
Но к большому сожалению, чудеса бывают только в сказках. Поэтому компании (это, как правило, был либо украинский аутсорс на Запад, либо Западный продукт по прямому контракту) нагружали меня дополнительно всем чем только можно. Мол ты же не разрабатываешь архитектуру по 8 часов в день каждый день, так что будь: тим лидом/тех лидом, системным аналитиком, помоги с кодом той или иной команде, поработай DevOps и самое противное — это, к нам зашел новый клиент на пресейл, поэтому нужно очень быстро оценить объем работы, расписать и заэстимейтить фичи с тасочками (извиняюсь за американизмы, все работа ведется только на английском языке).
Вот пресейлы я реально не люблю, так как для того, чтобы объективно оценить проект, нужно создать под него архитектуру. А за архитектуру на этапе дискавери (исследования бизнес требований) никто не хочет платить. Но очень часто бывает так, что в компании вообще нет таких людей, как солюшен архитекторы или системные архитекторы. И тогда пресейл менеджеры бегут к разработчикам и начинают их мучить, чтобы те быстро сделали эстимейты, желательно на вчера. Про чувства программистов писать не буду, уверен вы и так это знаете.
В итоге рождаются для клиента такие чудесные коммерческие предложения в Excel таблицах, как «Форма регистрации на сайте: 40 — 120 часов, $1600 — $4800». Вы можете это даже в Гугл поиске найти, на англоязычных сайтах. Это реальный пример из жизни. На уточняющий вопрос заказчика, что это вообще значит, менеджеры просто пожимают плечами, а клиент идет дальше искать «надежду» и здравомыслие в других компаниях.
Вот на пресейлах я и остановлюсь подробнее и расскажу всю боль, и как я решил ее уменьшить. Стоимость создания IT продукта напрямую зависит от времени, затраченного на его создание. А время уже в итоге умножается на рейт компании ($40 — $80), что дает в результате стоимость в деньгах. Поэтому, сосредоточимся на том, как правильно оценить временные затраты. Самый точный метод — это декомпозиция функционала на самые маленькие элементы, которые уже можно достаточно просто оценить. Как это сделать правильно?
Первое, что нужно сделать, — это собрать все бизнес-требования клиента и проанализировать их. Залог успеха и правильной оценки заключается в том, чтобы полностью прояснить для себя весь проект. Какова его цель, какие функции должны в нем быть, почему клиент видит реализацию своих идей именно так и т.д. Для того чтобы собрать все это в своей голове, необходимо создать бизнес-диаграмму (workflow), на которой графически изобразить весь функционал, связи между этим функционалом и все алгоритмы действий, которые должны работать в проекте. Этот воркфлоу нужно делать на высшем уровне, без углубления в детали. Это поможет сразу выделить очевидные места, которые можно относительно легко оценить. Например, система регистрации и авторизации, форма обратной связи и т.д. Для более сложных частей проекта придется делать более глубокую декомпозицию, разбивая все на отдельные функции, а функции — на более мелкие задачи.
С помощью такого подхода можно будет получить подробную документацию с множеством мелких задач, которые уже можно более или менее точно оценить, дав минимальную и максимальную временную оценку. В таком подходе есть как плюсы, так и минусы.
Главные плюсы — это максимально точная оценка и подробная проектная документация. Минус — большие временные затраты на оценку всех задач, и как следствие — большая стоимость затрат на дискавери сессию, которая может быть не оплачена. А также необходимо наличие специалистов с соответствующей квалификацией.
Есть еще ряд трудностей, с которыми сталкиваются разработчики при оценке проекта. Это сохранение и переиспользование оцененных ранее задач. Использование для расчетов Excel или других таблиц, что неудобно для работы и выглядит не слишком серьезно в глазах клиента. Плюс невозможность затем превратить полученный документ в реальный проект, например, в системе управления проектами Jira, Trello или другой. Также непонятно, где хранить наработки в виде диаграмм, схем и другой документации, созданной для задачи.
Иногда я встречал, что компании заводят новый проект на пресейл в систему прожект менеджмента, например в Jira. Делают там эстимейты, а потом строят отчеты. Но это отнимает огромное количество времени, и если проект в работу так и не взяли, то он становиться бесполезным грузом.
Мне очень часто приходилось сталкиваться с оценкой, как частей проекта и конкретного функционала, так и целых проектов, начиная от невнятной идеи заказчика. Это реально очень сложно и утомительно. Также это осложнялось тем, что компания, где я работал, а вернее все компании, где я работал, пытались повесить на меня кучу лишних обязанностей, которые я не очень люблю. И вместо создания архитектуры для продукта и помощи разработчикам в его создании, и доведения его до продакшена, меня вечно отвлекали на пресейлы.
Я много лет реально промучался с этой рутиной, каждый раз выполняя одни и те же действия, как обезьяна, оценивая проекты, фичи и таски для клиентов. И всегда бизнесу это нужно было на вчера. Меня из архитектора превратили в какого-то сейлза, от чего у меня невероятно начинало пригорать. И в какой-то момент я понял, что уже начинаю сдавать морально, и что пора что-то с этим делать. И я стал продумывать, как мне упростить свою жизнь. Вначале я пытался создавать проект в Jira, как я встречал это в других компаниях. Но это отнимало много времени и сил на настройку и структуру проекта. Стало скапливаться много независимых друг с другом проектов, многие из которых не уходили в работу. Это было жутко неудобно. Потом я начал сохранять эстимейты в виде текстовых закладок, потом создавал мелкие файлы и перепробовал много чего еще. Все это было неудобно и не давало гибкости и простоты в быстром переиспользовании уже проделанной работы.
И тогда я понял, что придется делать что-то свое, дабы убрать с моих плеч эту рутину. Задачу я себе поставил такую: нужно разбивать бизнес требования на маленькие задачи, которые я могу оценить в часах, как минимальное и максимальное время выполнения. Задачи должно быть легко создавать, сохранять и быстро находить. Из этих задач можно быстро собирать фичи (функционал). Я это видел как редактор, создал фичу и накидал туда готовые таски. При этом мне нужно было, чтобы эта фича уже сама посчитала все эстимейты исходя из тех задач, из которых она состоит. Таким образом я смогу накапливать функционал, который я уже описал и оценил. Следующий момент — это возможность создать новый проект для пресейла нового запроса от клиента. Быстро заполнить его фичами, а если чего-то у меня в базе нет, то создать только это и не более того. И конечно же быстро это сохранить в PDF файл, с простой, понятной структурой, где будет все описано подробно и понятно для заказчика. Ну а по мере необходимости я буду добавлять уже новый функционал.
И я сделал для себя черновой проект на NodeJS и ReactJS, и использовал его для своих целей. Потом понадобилось подключать и других инженеров для оценки времени, так как большие проекты декомпозировать и оценивать в одиночку очень сложно. И для этого пришлось добавлять возможность приглашения конкретного сотрудника, а сам проект сделать онлайн. После чего нужен был экспорт уже готового проекта в какую-нибудь систему прожект менеджмента.
Но проект стал усложняться и разрастаться, и в итоге, я решил сделать SaaS-сервис. Назвал его соответственно — Presale.Ninja Чтобы название проекта говорило само за себя. А нинзя, потому, что это крутой уровень мастерства )) На самом деле домен .com и все другие были заняты, а нинзя свободен, вот и все дела. Весь функционал полностью бесплатный. Единственное ограничение я сделал на количество итоговых задач в самом проекте. Это 30 задач, которые высчитываются из фич. Для большинства нужд небольших проектов этого достаточно, а фрилансерам так и подавно. А если нужно больше, то можно докупить, стоит это копейки. Для крупных проектов компаний, стоимость создания большого проекта будет обходится в 10 — 20 раз дешевле, чем эстимейтить по старинке.
Как это работает? Когда вы только начинаете пользоваться сервисом, вам не уйти от стандартного подхода декомпозиции и оценки задач. Но зато ваши инженеры могут работать не по одному, а сразу командой, создавая в сервисе задачи, которые будут оценены с минимальным и максимальным эстимейтом на выполнение. К задаче можно прикрепить все файлы, связанные с ней. Позднее это пригодится, когда проект нужно будет импортировать в систему управления проектами.
Задача (task) — это минимальный элемент, являющийся продуктом нашей декомпозиции. У задачи есть заголовок и описание (title и description). Также, как было сказано выше, к задаче можно добавить файлы, которые к ней относятся. У задачи есть автор. Для быстрого поиска задач можно добавлять к ним различные теги (tags), которые можно создать в разделе тегов. Теги сильно облегчают поиск, когда нужно что-то быстро найти. И, естественно, у задачи есть два поля для эстимейтов в часах — минимальный и максимальный.
Теперь, когда у нас есть большое количество мелких и хорошо описанных задач, мы можем создавать фичи (feature). Фича состоит из ряда этих мелких задач. Например, функционал «Регистрация». Он включает такие задачи, как создание миграции в базе данных, создание моделей для таблиц, создание контроллеров и API для регистрации и авторизации, формы регистрации и авторизации на фронтенде, дизайн, верстка и т.д. Создание фичи также легко, как и создание задачи, даже проще. Нужно создать фичу, заполнить заголовок и описание, прикрепить теги для быстрого поиска, а затем в разделе билдера (builder) наполнить фичу соответствующими задачами. Это, также, задача инженера. В итоге будет создана фича с описанием, списком задач, автором и суммарным эстимейтом от минимума до максимума. Все это сохраняется в облаке сервиса для компании, которая создала этот функционал. В дальнейшем не нужно будет снова проводить эстимейты того, что уже содержится в базе. Можно все это переиспользовать в новых проектах.
Далее нужно создать проект, который может создать сам менеджер по работе с клиентом. Проект также содержит заголовок, описание, возможность добавить теги. После этого можно перейти в билдер проекта и выбрать фичи, которые нужны клиенту для этого проекта. Менеджер может сделать все это самостоятельно, не отвлекая инженеров от их работы. Если окажется, что нужной фичи нет в базе знаний, менеджер может привлечь инженеров, чтобы те помогли создать недостающие задачи и фичи для проекта. Можно приглашать коллег через раздел инвайтов (invite), назначая им соответствующие роли для доступа к определенному функционалу сервиса.
После этого можно просмотреть, как будет выглядеть финальный документ в предпросмотре (preview), и сохранить его в формате PDF для передачи клиенту. Это будет полноценный документ, содержащий заголовок и описание проекта, список всех фич и задач, а также эстимейты — для фич, задач и для всего проекта. Фича в документе будет отображать сумму всех эстимейтов своих задач. Документ будет содержать заголовки и описания для всех фич и задач в иерархическом виде, что поможет клиенту понять, за что ему предстоит заплатить. Чем более подробно будут декомпозированы задачи с минимальными эстимейтами, тем выше вероятность устранить вопросы клиента о стоимости или сроках. Все будет перед глазами, ясно и очевидно. Это значительно повысит вероятность получения этого заказа.
Меня попросили добавить в сервис еще одну возможность. А именно шапку и футер для проекта (Header & footer). Это нужно, чтобы в шапке указать логотип и контакты компании, которая произвела пресейл проекта. А в футере, внизу документа, добавить дополнительную информацию. Например, что это не окончательные расчеты, и все подлежит обсуждению. Что в эстимейты не входит время на прожект менеджмент и тестирование, и т.д.
Когда проект будет принят в работу, возникнет вопрос о том, какие фичи и задачи нужно создать для разработчиков и на какую документацию им опираться. Для этого проект можно экспортировать в формате JSON, а затем импортировать его в систему управления проектами. При экспорте проекта вы получите ZIP-файл, содержащий ваш проект в формате JSON, а также папки с названиями задач из проекта, в которых будут находиться файлы, относящиеся к соответствующим задачам.
Сервис не заставляет вас действовать по определенным шаблонам, и вы можете построить гибкую систему, применяя разные подходы в создании задач и фич, которые будут подходить именно для вашей компании и команды. Все зависит от вашего воображения. Система поиска по тегам и строка поиска по текстам в заголовках и описаниях значительно упростят вашу работу.
Вот и все — очень просто и эффективно. В итоге сервис может сохранять всю базу знаний по предыдущим эстимейтам, уменьшить зависимость от инженеров, быстро создавать новые проекты, создавать профессиональную документацию, а также переносить проекты в систему управления проектами. Лично меня это полностью избавило (почти избавило) от рутинных операций и сократило потери времени. А для компании повысило экспертизу в глазах клиентов.
P. S. Был один курьезный случай. Маленькая WEB студия из трех человек сделала через сервис оценку проекта, по запросу заказчика. И заказчик согласился с ними работать. Они были в шоке, как так получилось. Этот заказчик делал запрос также в среднюю аутсорсинговую компанию. И та выдала ему эксел файлик на одну страничку, примерно с такими же эстимейтами, и в таком же виде, как я рассказывал вначале статьи. И заказчик решил, что эта аутсорсинговая компания и есть подвальная студия, а эти ребята из студии — это реальные профессионалы. Как гласит старая мудрость: «Встречают по одежке». Всем удачи в ваших начинаниях!
ссылка на оригинал статьи https://habr.com/ru/articles/873846/
Добавить комментарий