У нас есть два основных принципа:
- Команда делает проекты качественно, в срок и с прибылью для компании;
- Большинство решений, связанных с реализацией проектов, команда принимает самостоятельно, так как основные процессы в компании автоматизированы и прозрачны.
Проект любого масштаба мы разделяем на семь обязательных этапов.
1. Выбираем методологию
От этого зависит состав команды, порядок и даже график работы. Можно выбрать классическую (waterfall) или гибкую (agile).
При классической методологии:
Команда будет работать строго по ТЗ. Результат, который вы получите в итоге, будет ровно таким, каким вы его запланировали в самом начале.
При гибкой методологии:
Команда сможет решать вопросы «на ходу», подстраиваться под рынок и менять требования в моменте. Результат, который вы получите «на выходе», может сильно отличаться от предполагаемого.
Если вам нужно быстро запустить MVP-версию продукта и понять, в каком направлении его развивать – выбирайте гибкую методологию.
К — коммуникация! Постройте основные бизнес-процессы в своей компании
2. Определяем роли и состав команды
Решив, по какой методологии вы будете делать проект, легче понять, кого набирать в команду и как делегировать задачи. Определите, какие специалисты нужны под проект. Основную экспертизу держите внутри компании, а «руки» можно подключить и на аутсорс.
Классический отдел разработки состоит из следующих сотрудников:
- менеджер проекта: контролирует рабочий процесс, дедлайны, оптимизирует работу сотрудников;
- архитектор: определяет стек технологий, проектирует общую инфраструктуру проекта, его основные компоненты, модули и сервисы;
- frontend- и backend-разработчик/fullstack-разработчик: первые занимаются визуальной и вычислительной частью проекта, а второй, как универсальный солдат, владеет знаниями разных технологий;
- тестировщик: обеспечивает качество программного продукта с самого начала разработки и до его финальной сдачи;
- тимлид: декомпозирует и делегирует задачи, проводит код-ревью и поддерживает боевой дух команды;
- дизайнер: определяет внешний вид продукта, его интерфейс и юзабилити;
- аналитик: проектирует и оптимизирует процессы, руководит внедрением новых IT-систем и адаптирует систему работы к новым задачам;
- системный администратор: осуществляет бесперебойную работу серверов, настраивает площадки для разработчиков и обеспечивает техническую инфраструктуру.
В некоторых из них нет необходимости, если проект небольшой – например, в архитекторе или аналитике. Главное: берите профессионалов, на которых сможете положиться и которые в состоянии принять решение по специфичным вопросам.
3. Проводим CustDev, собираем требования с клиентов, пишем техническое задание
Опросите конечных пользователей, чтобы выявить их потребности и получить максимально реалистичный прототип продукта. Такое исследование нужно провести «на берегу», до начала рабочих действий по проекту, чтобы конечный продукт был жизнеспособен и чтобы сделать продукт под запрос, а не наоборот.
Уделите внимание техническому заданию. ТЗ – гарант, что вы не потратите время зря, не переплатите и получите нужный результат. Кроме того, оно обеспечивает техническое развитие продукта и поможет:
- оценить задачу по бюджету, срокам и объему человеко-часов;
- упростить сдачу-приемку проекта;
- объяснить специалисту, как устроена работа проекта и какую документацию нужно готовить «на выходе».
4. Обеспечиваем команду техническими инструментами
За настройку технической инфраструктуры отвечает системный администратор. Строить боевую инфраструктуру сразу не обязательно – выполните минимальную часть, чтобы обеспечить команде место для работы.
- репозиторий для кодовой базы проекта;
- общие инструменты организации процесса разработки, если они нужны – например, таск-трекер (Jira, Redmine, Trello и другие);
- рабочее окружение: сервисы и приложения, от которых будет зависеть ваш продукт (например, Swagger для документации API).
Убедитесь, что у всех членов команды имеется доступ к инструментам разработки и рабочему окружению.
Задача сисадмина – предоставить стабильную и актуальную платформу для разработки проекта, настроить боевое окружение и обеспечить его поддержку.
Учитывайте, в каких условиях будет работать продукт. Среда разработки должна быть максимально приближена к боевой.
5. Планируем работу команды
Постройте график реализации проекта, по которому будет работать вся команда. Распишите сроки по каждой задаче и определите финальную дату готовности проекта.
Составляя график, учитывайте сдвиг сроков задач (например, увеличение сроков из-за исправлений ошибок) и продумайте, как одна задача зависит от другой.
Например, нет смысла разрабатывать оформление заказа, пока не разработаешь корзину или каталог. Тестировщик не сможет проверить задачу, пока не положит товар в корзину. Лучше делегировать эту задачу одному человеку, чтобы он делал корзину, а затем оформление.
Здесь же декомпозируйте по задачам техническое задание. Разбейте его на небольшие задачи и распределите трудовые ресурсы так, чтобы каждый сотрудник был полностью загружен задачами.
Постарайтесь избавиться от крупных задач — их сложно оценивать, контролировать, тестировать и запускать в релиз. В таких задачах гораздо чаще встречаются ошибки после релиза в боевую среду. Если задача занимает более 20-человека-часов — декомпозируйте ее на мелкие, иначе она рискует превратиться в «болото».
6. Делегируем задачи, контролируем их выполнение
Делегирование — задача тимлида, который соотносит сложность задачи с уровнем специалистов. Он не отдаст младшему специалисту задачи, которые ему «не по зубам», или обеспечит поддержку, которая позволит ему выполнить задачи правильно.
Убедитесь, что разработчик верно понял задачу. Перед стартом соберите команду вместе и обговорите все этапы работы: каждый должен понимать, что делает команда в целом и какова его роль в этом процессе.
На протяжении всего процесса разработки тимлид помогает членам команды в решении сложных технических вопросов и держит в фокусе общую картину проекта. Он учитывает ее, чтобы принимать решения о последовательности задач и распределении трудовых ресурсов.
Контролируйте сроки — например, можно проводить ежедневные или еженедельные встречи с командой. Это поможет держать руку на пульсе, следить за этапами реализации проекта и вовремя решать возникающие сложности.
Неважно, какую методологию ведения проекта вы выбрали — гибкую или классическую. Следите за сроками: работа над проектом часто превращается в рутину, где легко зациклиться на мелких задачах. Не засыпайте! Отсекайте лишнюю работу, проверяйте задачи и сводите их в единое целое, чтобы адекватно оценить готовность проекта.
7. Выкладываем, тестируем и дорабатываем продукт
Тестирование каждой задачи повышает качество продукта и бережет вас от дефектного релиза с ошибками. Не забудьте про код-ревью — проверку кода, который написал разработчик. Обычно ревью проводит тимлид проекта или кто-то из старших разработчиков. Если возникают спорные моменты, привлекайте автора кода.
Перед выкладкой проведите пусконаладочные работы. Это финальный этап разработки перед запуском: продукт готовят к работе в боевой среде, и команда настраивает боевую инфраструктуру. Не забудьте про системы логирования, резервного копирования и прочие системы выявления сбоев и устранения их последствий.
После этого продукт выкатывается в боевую среду, его финально проверяют тестировщики.
Цифровой продукт нельзя сделать раз и навсегда. Поддерживайте его работу, чтобы он оставался актуальным и полезным для пользователей.
Помните, что завершенных проектов не бывает. Ошибки находят даже после выпуска продукта. Следите за ним даже после успешного выпуска и вовремя исправляйте дефекты.
Чтобы организовать процесс разработки, который будет работать без вашего участия:
- Отталкивайтесь от методологии: она определит, как, в каком составе и в какие сроки вы будете работать;
- Создайте команду специалистов и определите роль каждого: на самостоятельную команду можно положиться, ведь она сама принимает решения;
- Не работайте вслепую: отталкивайтесь от запросов клиентов и создайте понятное, ясное и четкое техническое задание;
- Обеспечьте рабочее пространство: для разработчиков это не только кресло, стол, кофе и печеньки, а репозиторий, технические инструменты и рабочее окружение;
- Составьте график реализации проекта: разбивайте большие задачи на мелкие и следите, чтобы рабочий процесс был логичен, а разработчики не сидели без дела;
- Назначьте ответственного по каждой задаче и контролируйте срок ее выполнения: так вам не придется удивлять разработчиков их «новыми» обязанностями спустя месяц со старта, и вы не затянете процесс даже при гибкой методологии;
Следите за продуктом даже после релиза: в IT-индустрии ни одно решение не будет работать вечно. Обновляйте модули, добавляйте новые технологии и инструменты, чтобы продукт всегда был актуальным.
Источник: rb.ru
Основные бизнес процессы it компании
Выявление требований — важнейший этап в управлении продуктом, позволяющий преобразовать потребности рынка в четкие, понятные требования к продукту. Вот пошаговое руководство, которое поможет вам в этом процессе:
Поймите требования рынка :
Начните с тщательного изучения требований рынка. Убедитесь, что вы понимаете основные потребности или проблемы, которые эти требования призваны решить.
Выявите заинтересованные стороны :
Определите всех заинтересованных лиц, на которых будут влиять эти требования или те, кто может повлиять на них. Сюда могут входить клиенты, отделы продаж, команды разработчиков и руководители.
Создайте стандартный шаблон :
Разработайте стандартный шаблон для требований к продукту, чтобы обеспечить единообразие. Он может включать такие поля, как идентификатор требования, описание, обоснование, приоритет и критерии оценки.
Перепишите рыночные требования как требования к продукту :
Используя свой шаблон, переработайте каждое рыночное требование как требование к продукту. Убедитесь, что формулировки ясны, конкретны и понятны всем заинтересованным сторонам.
Определите похожие требования :
Ищите требования, которые описывают схожую функциональность. Сгруппируйте их вместе или создайте иерархическую структуру, чтобы избежать избыточности.
Определите приоритеты требований :
Определите приоритеты требований к продукту на основе таких факторов, как их влияние, выполнимость и соответствие бизнес-целям. Вы можете использовать систему расстановки приоритетов, такую как MoSCoW или RICE.
Проверьте и утвердите :
Обсудите требования к продукту с заинтересованными сторонами. Убедитесь, что требования точно отражают потребности рынка и что их возможно реализовать.
Документируйте требования :
Задокументируйте требования к продукту в документе о требованиях к продукту (
или PRD) или подобном инструменте. Убедитесь, что вся необходимая информация содержится в документе и что она организована таким образом, чтобы ее было легко понять.
Сопровождайте и обновляйте требования :
По мере разработки или получения новой информации вам может понадобиться обновить требования.
Убедитесь, что все изменения доведены до сведения всех заинтересованных сторон.
Помните , что выявление требований — это итерационный процесс. Возможно, вам придется неоднократно пересматривать и пересматривать требования по мере сбора дополнительной информации и по мере разработки продукта. Регулярное общение и сотрудничество с заинтересованными сторонами является ключевым моментом в этом процессе.
Вовлечение внутренних заинтересованных сторон
Вовлечение внутренних заинтересованных сторон в процесс управления продуктом имеет решающее значение для принятия хорошо обоснованных решений и обеспечения единства действий всех участников в достижении общей цели. Ниже приводится пошаговое руководство для менеджеров продуктов по привлечению внутренних заинтересованных сторон:
Определите значимые внутренние заинтересованные стороны:
Определите всех внутренних заинтересованных лиц, которые вовлечены в жизненный цикл продукта. Как правило, сюда входят такие роли, как менеджеры по продуктам, служба поддержки, службы сервиса, разработки, продаж и маркетинга, а также исследований и развития.
Донесите цель и порядок действий:
Четко объясните цель вовлечения заинтересованных сторон в процесс управления продуктом и то, как будет использоваться их вклад. Объясните процесс, который вы будете использовать для сбора их вклада и принятия решений.
Поделитесь требованиями к продукту:
Поделитесь списком требований к продукту со всеми заинтересованными сторонами. Убедитесь, что они понимают каждое требование и его цель.
Запросите информацию о расстановке приоритетов:
Попросите каждую заинтересованную сторону определить приоритеты требований с их точки зрения. Убедитесь, что они понимают, как расставлять приоритеты. Вы можете использовать систему расстановки приоритетов, например, MoSCoW или RICE, или простую систему ранжирования или подсчета баллов.
Сбор и агрегирование данных:
Соберите списки приоритетов от каждой заинтересованной стороны. Агрегируйте эти данные, чтобы получить целостное представление о приоритетах.
Обсудите и разрешите конфликты:
Если в приоритетах есть конфликты или разногласия, проведите обсуждение для их разрешения. Постарайтесь понять, чем обоснованы приоритеты каждой из заинтересованных сторон, и найдите компромисс, который наилучшим образом удовлетворит потребности бизнеса и пользователей.
Окончательно утвердите приоритеты:
На основе обобщенных данных и любых обсуждений окончательно определите приоритеты для требований к продукту.
Документирование и коммуникация:
Зафиксируйте окончательные приоритеты и все важные обсуждения и решения. Поделитесь этой информацией со всеми заинтересованными сторонами, чтобы все понимали приоритеты и то, как принимались решения.
Вовлекайте заинтересованные стороны в регулярные обзоры:
Вовлекайте заинтересованные стороны в регулярные обзоры продукта, где вы сможете обсудить прогресс, получить обратную связь и внести необходимые коррективы.
Помните , что привлечение заинтересованных сторон — это не разовое мероприятие, а постоянный процесс. Регулярное общение и сотрудничество с заинтересованными сторонами — залог успешного управления продуктом.
Плаирование релиза
Выбор основных требований к выпуску продукта является важнейшим этапом в процессе управления продуктом. Этот шаг гарантирует, что наиболее важные и реализуемые функции будут включены в предстоящий релиз. Вот пошаговое руководство, которое поможет вам в этом процессе:
Понймите потенциал инженеров:
Начните с понимания возможностей вашей инженерной команды. Сюда входят такие факторы, как количество разработчиков, их навыки, время, доступное для выпуска релиза, и любые другие ресурсы или ограничения.
Изучите требования к продукту:
Изучите список всех требований к продукту. Убедитесь, что вы понимаете каждое требование и его важность для продукта.
Оцените усилия для каждого требования:
Совместно с командой инженеров оцените усилия, необходимые для реализации каждого требования. Эти оценки должны учитывать такие факторы, как сложность требования, необходимые навыки и любые зависимости между требованиями.
Определите приоритеты требований:
Расставьте приоритеты требований на основе их важности для продукта и усилий, необходимых для их реализации. Вы можете использовать систему расстановки приоритетов, например, MoSCoW или RICE, или простую систему ранжирования или подсчета баллов.
Выберите требования для выпуска:
Основываясь на приоритетах и инженерных возможностях, выберите требования для включения в следующий релиз. Начните с самых приоритетных требований и продолжайте добавлять требования, пока не достигнете предела возможностей. Обязательно оставьте некоторый запас на случай непредвиденных проблем или задержек.
Обсудите выбранные требования с заинтересованными сторонами:
Рассмотрите отобранные требования с заинтересованными сторонами, включая команду инженеров и других внутренних заинтересованных лиц. Соберите их отзывы и внесите необходимые изменения.
Завершите разработку релиза:
На основе полученных отзывов завершите выбор требований для следующего выпуска.
Документирование и коммуникация:
Задокументируйте результаты разработки релиза в четком и понятном формате.
Ознакомьте с ним всех заинтересованных лиц , чтобы все понимали, что и почему будет включено в следующий релиз.
Помните , что выбор требований к релизу — это балансирование между желаемым (наиболее приоритетные требования) и выполнимым (то, что может быть достигнуто с учетом инженерных возможностей). Регулярное общение и сотрудничество с инженерной командой и другими заинтересованными сторонами являются ключевыми в этом процессе.
Источник: coda.io
Как эффективно управлять бизнес-процессами в IT-компании
Одной из распространенных проблем российского бизнеса, в целом, и IT-отрасли, в частности, являются бизнес-процессы, а если точнее, распространенные проблемы в управлении ими. Отчасти, они вызваны недостаточными компетенциями руководителей, но ещё чаще – формальным подходом к процессам, который снижает эффективность работы компаний.
Характерной особенностью управления БП в российских компаниях является проблема обратной связи и ориентации процессов на конкретные результаты. Именно эта особенность вызывает характерные ошибки, о предотвращении которых пойдет речь. Далее, о важности правильного построения бизнес-процессов в ИТ и о снижении рисков, связанных с неверными подходами к управлению ими.
Ошибки и проблемы
Наибольшие сложности при управлении БП в российских ИТ-компаниях связаны с распространенными ошибками, которые совершает менеджмент. Одной из них является фиксация на самом процессе и формальных показателях, которые его отражают, но не на результате такого процесса.
В таком случае постулируется, что наиболее значимым для сотрудников является соблюдение регламента и выполнение его является условием гарантированного результата, что верно далеко не всегда. Фиксация на процессном подходе возникает тогда, когда руководитель хочет получить результаты, выполняя четкие инструкции, не вникая в суть деятельности компании или подразделения.
Как правило, в подобных случаях регламентируется всё, хотя бы отдаленно напоминающее бизнес-процесс, при этом у руководства и сотрудников нет понимания, зачем существуют те или иные регламенты. Основные преимущества процессного подхода позволяют ускорить работу компании и добиться большей эффективности, чего не происходит в подобных случаях.
Проблемой становится бюрократия, как следствие гиперрегламентации. Бюрократическое затягивание и отсутствие связи между регламентом и результатом неприемлемо и для IT-компаний, особенно, если речь идёт об аутсорсинге или продуктовых компаниях в тех сегментах рынка, где велика конкуренция.
Так, в случае аутсорсинга перспективный клиент не станет ждать нужного решения вечно и уйдёт к конкуренту с близкими компетенциями и более эффективными подходами. Аналогично в продуктовой компании, особенно на стадиях, когда пользователи только становятся лояльными к продукту, обновления и изменения необходимо осуществлять максимально быстро.
Неправильно выстроенные регламенты не помогают, а напротив, мешают. Порой их полное отсутствие в IT-бизнесе при интуитивном понимании сути процессов компании работает лучше четкого соблюдения жестких регламентов, не соответствующих текущим целям бизнеса. Важно помнить, что процессы, их моделирование и регламентация являются средствами, а не целью.
Без регламентов нельзя управлять процессами в крупной компании, но они должны быть гибкими, соответствовать условиям и текущим целям. Аналогичные ошибки совершают в отношении показателей эффективности. KPI совсем не панацея, как и другие количественные показатели.
В ИТ бизнесе очень многое зависит от оценки конечного пользователя, соответствия продукта или сервиса его требованиям. На этом фоне измеримые показатели не всегда корректно отражают реальность и вклад сотрудников. Таким образом, крайне важно исходить при оценке эффективности, в первую очередь, из реализации требований.
Операционная деятельность
Выстраивая бизнес-процессы важно, определить операционные модели деятельности компании, сервисные, проектные. Четко их разграничивать или и комбинировать при необходимости. Корректность в таком определении требуется, в связи с тем, что каждая модель имеет принципиально различные механизмы управления.
Правильное применение процессов при ведении операционной деятельности позволяет использовать ресурсы предприятия эффективно. В противном случае возникают несоответствия, которые закономерно приведут к убыткам.
Например когда “дорогие” специалисты с квалификацией соответствующей проектной модели, осуществляют сервисные функции, что делает сервис избыточно ресурсоемким для заказчика. В особенности это заметно при формировании кадровой политики, а в случае с ИТ человеческий ресурс является самым значимым. При ведении сервисной деятельности требования к ресурсу заметно различны с проектной. Это касается как квалификации, так и требований к организации рабочего пространства и подходов в управлении.
Практические примеры оптимизации БП из деятельности ЕАЕ-Консалт
HR Проблема при увольнении сотрудники часто просили направить оригиналы справок. Обращались к тем, с кем контактировали во время работы. Они направляли информацию в кадры и бухгалтерию, а те в свою очередь формировали справки и направляли на подпись секретарю. При этом основными контактными данными был адрес.
После подписи оригиналы справок направлялись в адрес уволившегося сотрудника по почте. Нередко справки возвращались, а уволенные сотрудники повторно обращались, и круг повторялся. При этом действовавший в то время регламент выполнялся для каждого участника процесса, но результата фактически не было, а временной ресурс расходовался.
Что сделали Для обращения от уволившегося сотрудника сделали обязательным вместе с адресом предоставление информации об актуальном номере телефона и типе мессенджера для отправки уведомления. В СЭД формировалась задача с указанием всех задействованных лиц, а секретарю дополнительно ставилась задача направить трек-номер отправления для отслеживания в мессенджер.
Итог: возврат справок прекратился. Тендерный отдел Проблема Тендеры искали специалисты по подготовке тендерной документации. Что им казалось подходящим, направляли руководителям подразделений на рассмотрение и далее принималось решение об участии или неучастии.
На этом процессе часть тендеров «терялась», причиной чего становилась субъективная оценка тендерного специалиста. Статистика по количеству и объему (в деньгах) таких процедур не велась. Что сделали Настроили список ключевых слов в поисковой системе, каждый найденный тендер стал попадать в отдельную карточку и сразу направлялся руководителю направления для формальной оценки.
Если тендер подходит, то запускается стандартный процесс оформления. Если не подходит, то данные о нём попадают в статистику. Указывается сколько раз в месяц и по какой причине проводится ревью ключевых и стоп-слов. Также стала собираться статистика, позволяющая принять решения об изменениях в компании, которые позволят участвовать в большем количестве тендеров.
Итог Количество тендеров стало увеличиваться. Если раньше такие факторы игнорировались, то после изменений процесса, стали учитываться. Начался поиск дополнительных специалистов, переобучение сотрудников и получение необходимых сертификатов, компетенций, в соответствии с полученными данными.
Что важно учитывать при управлении процессами в ИТ?
- Цели
- Ресурсы
- Этапы и действия, их последовательность
- Характер деятельности в описанных процессах
- Критерии и методики оценки эффективности (качества)
- Связи каждого этапа и процесса в целом.
Если этой информации нет, регламенты для процессов строить нельзя. Они не будут эффективными и, вероятно, осложнят работу IT-компании. Учет этих данных, напротив, упрощает управление и позволяет получить ожидаемый результат.
Источник: www.it-world.ru