Станислав Триерс
эксперт программы для студентов Moove от бизнес-школы «Сколково» и МТС, гендиректор компании Tess Technology
Лучше всего рассматривать структуру команды в компаниях от 10 человек. В ней, как правило, также есть и второстепенные функции (бухгалтерия, юристы, клининг и т. д.). Их чаще всего отдают на аутсорс. Кроме того, в компании должны быть продавцы, маркетологи и HR.
На начальном этапе директор может справляться с частью функций сам (продавать, продвигать услуги, искать и нанимать сотрудников). Такая ситуация характерна, прежде всего, для стартапов, где команда может брать на себя все функции сразу. Так как это недавно запущенный проект, и его цель – окупить инвестиции и получить прибыль в максимально короткие сроки, директор может быть и продавцом, и разработчиком, и курьером. Однако чаще всего там уже есть деление на сферы ответственности. Например, в команде LICA (разрабатывают ИТ-продукт по подбору станков и тканей для текстильной промышленности), которую я курирую на программе Moove, кто-то взял на себя роль CEO, кто-то — CTO, а кто-то занялся продажами и общением с клиентами.
Ребята сами поделили сферы ответственности, исходя из компетенций и собственного опыта. Попытки перекинуть непрофильные задачи на других членов команды приводили к конфликтам (так, например, обзвон базы клиентов для технического специалиста был проблемой, он отказывался это делать). В итоге пришли к тому, что у каждого есть своя сфера ответственности и задачи изначально делятся по этим сферам.
По мере роста компании необходимо выделять под каждую функцию отдельного сотрудника. В классической компании, занимающейся разработкой программного обеспечения под заказ, так и происходит. Нагляднее всего это видно на этапах создания ПО.
Этапы создания ПО:
- создание концепции/ТЗ;
- проработка архитектуры программного обеспечения;
- создание технической документации;
- реализация проекта;
- тестирование и приемка;
- внедрение;
- техническая поддержка.
На каждом этапе должен быть свой отдел со своими задачами:
- проектный офис;
- отдел проектирования программного обеспечения;
- отдел тестирования и документирования;
- отдел разработки;
- отдел внедрения и сопровождения.
Основной состав группы — это специалисты, полностью занятые в создании нового программного продукта:
- менеджеры проекта;
- программисты;
- тестировщики;
- разработчики документации;
- инженерные психологи;
- технологи по разработке ПО.
Вспомогательная группа — это специалисты, не занимающиеся созданием программ, но, тем не менее, играющие важную роль в реализации проекта:
- группа менеджмента и маркетинга продукта;
- специалисты по технической поддержке ПО;
- администраторы бета-тестирования.
По сути в любой команде, занимающейся разработкой продукта, можно выделить следующие роли в команде:
Developer
Занимается производством программных продуктов.
Это роль исполнителя: руководитель ставит задачу на автоматизацию того или иного процесса, разработчик ее выполняет. Эта роль часто сегментируется:
по разделению ответственности:
- Backend developer — разработчик программно-аппаратной части комплексного ПО;
- Frontend developer — разработчик клиентской стороны пользовательского интерфейса к программно-аппаратной части.
по платформам:
- Web;
- Mobile;
- Server-Side;
- и так далее.
User Experience Designer (UX)
Занимается производством карт пользовательского опыта.
Этот человек изучает и оценивает, как пользователи относятся к разрабатываемому программному обеспечению. На нем лежит ответственность за то, чтобы продукт был прост в использовании, восприятии ценности, полезности и эффективности. Он продумывает и оценивает процессы и сценарии использования ПО.
Эту роль ошибочно путают, а порою и совмещают с ролью UI Designer. UX и UI Designer отличаются не только предметной областью, но и спецификой мышления. UX Designer больше про аналитику и систематизацию, чем про эргономику и эстетику.
User Interface Designer (UI)
Занимается производством графической составляющей интерфейсов.
Этот человек разрабатывает визуальную часть пользовательского интерфейса. Основными целями работы UI дизайнера являются: интуитивность восприятия, простота, юзабилити и эстетика интерфейса ПО.
Quality Assurance (QA)
Занимается проверкой результата.
QA занимается тестированием всего, как бы странно это ни звучало.
Системный подход специалиста QA позволяет тестировать как программный код, так и продуманность карт пользовательского опыта.
Human Resource (HR)
Занимается первичным подбором кандидатов.
Он обеспечивает прозрачное прохождение всех этапов собеседований при трудоустройстве.
Team Leader
Отвечает за работу группы специалистов.
Team Leader обеспечивает комфортные условия работы коллектива и поддерживает высокий уровень эффективности команды. Этот человек не обязательно должен знать специфику работы команды досконально. Например, Team Leader в группе разработчиков не обязан быть программистом, ему достаточно понимать как организовать работу, понимать процессы, протекающие во время производства.
Но на практике исторически сложилось, что на эту позицию ставят самых прокачанных программистов, что является классической ошибкой управления.
Tech Leader
Отвечает за грамотный аргументированный выбор технических решений:
- Ответственный выбор стороннего ПО для проекта;
- Рекомендация по выбору конкретного алгоритма или архитектурного решения при производстве ПО;
- Определение технических особенностей в процессах производства.
Scrum Master
Scrum, Agile, KanBan, гибкие методологии, и прочие теоретические знания, которые крайне бесполезны без практики и опыта.
Scrum Master — это специалист, который помогает команде применять методологию Scrum правильно, объясняет правила методологии, контролирует их выполнение. Сейчас к командам разработки стали прикреплять роль Scram Master. Он отвечает за грамотное применение той или иной гибкой методологии (бывает, что даже той, которая не касается Scrum вообще).
Project Manager (PjM)
Отвечает за старт, ведение и сдачу проектных работ.
Эта роль классического управленца процессами. Работа над проектом начинается с Project Manager’а, ведётся (ставит задачи), контролируется (контроль качества и эффективности) и сдаётся тоже им. В большинстве компаний Project Manager управляет проектным фондом.
Архитектор (Architect)
Ключевая обязанность архитектора — проектирование архитектуры ПО, т. е. принятие ключевых проектных решений относительно внутреннего устройства программной системы и её технических интерфейсов.
Бизнес Аналитик (Business Analyst)
Напрямую общается с заказчиками продукта и выясняет их пожелания и требования. Задача бизнес аналитика верхнеуровнево понять, чего хочет заказчик, как он видит продукт, который будет разрабатывать команда, цель у продукта и какие задачи он будет решать. На момент общения с заказчиком бизнес аналитик может предлагать свои идеи по улучшению продукта и совместно с заказчиком формировать так называемый vision.
Системный аналитик (System Analyst)
Занимается, в основном, анализом данных и принятием решений о том, как будет работать система, какие методы будут использоваться, а также написанием основных технических документов (техническое задание или ТЗ, спецификации). Важная часть работы — функциональный анализ, в результате которого выделяется перечень функций, которые должна выполнять система, а также определение требований к системе.
Технический писатель (Technical writer)
Специалист, который занимается составлением документации в рамках разработки различных программ. Это люди, которые призваны помогать нам овладевать новыми технологиями, будь то модное устройство или новая программа. От них отчасти зависит успех новинки, ведь именно им нужно убедить потенциального покупателя в пользе этой новинки и объяснить, как ей пользоваться.
Создание программных продуктов – головная боль для многих руководителей. Нужно правильно поставить задачу разработчикам, знать, как их контролировать, всегда иметь возможность оперативно внести изменения или «откатить» релиз, если в продукте нашли критическую ошибку.
Генрик Мкртчян — сооснователь и генеральный директор агентства веб-разработки «Кодеры», рассказал, как под ключ организовать процесс разработки в компании: от постановки задач до релиза продукта.
У нас есть два основных принципа:
- Команда делает проекты качественно, в срок и с прибылью для компании;
- Большинство решений, связанных с реализацией проектов, команда принимает самостоятельно, так как основные процессы в компании автоматизированы и прозрачны.
Проект любого масштаба мы разделяем на семь обязательных этапов.
1. Выбираем методологию
От этого зависит состав команды, порядок и даже график работы. Можно выбрать классическую (waterfall) или гибкую (agile).
При классической методологии:
Команда будет работать строго по ТЗ. Результат, который вы получите в итоге, будет ровно таким, каким вы его запланировали в самом начале.
При гибкой методологии:
Команда сможет решать вопросы «на ходу», подстраиваться под рынок и менять требования в моменте. Результат, который вы получите «на выходе», может сильно отличаться от предполагаемого.
Если вам нужно быстро запустить MVP-версию продукта и понять, в каком направлении его развивать – выбирайте гибкую методологию.
2. Определяем роли и состав команды
Решив, по какой методологии вы будете делать проект, легче понять, кого набирать в команду и как делегировать задачи. Определите, какие специалисты нужны под проект. Основную экспертизу держите внутри компании, а «руки» можно подключить и на аутсорс.
Классический отдел разработки состоит из следующих сотрудников:
- менеджер проекта: контролирует рабочий процесс, дедлайны, оптимизирует работу сотрудников;
- архитектор: определяет стек технологий, проектирует общую инфраструктуру проекта, его основные компоненты, модули и сервисы;
- frontend- и backend-разработчик/fullstack-разработчик: первые занимаются визуальной и вычислительной частью проекта, а второй, как универсальный солдат, владеет знаниями разных технологий;
- тестировщик: обеспечивает качество программного продукта с самого начала разработки и до его финальной сдачи;
- тимлид: декомпозирует и делегирует задачи, проводит код-ревью и поддерживает боевой дух команды;
- дизайнер: определяет внешний вид продукта, его интерфейс и юзабилити;
- аналитик: проектирует и оптимизирует процессы, руководит внедрением новых IT-систем и адаптирует систему работы к новым задачам;
- системный администратор: осуществляет бесперебойную работу серверов, настраивает площадки для разработчиков и обеспечивает техническую инфраструктуру.
В некоторых из них нет необходимости, если проект небольшой – например, в архитекторе или аналитике. Главное: берите профессионалов, на которых сможете положиться и которые в состоянии принять решение по специфичным вопросам.
3. Проводим CustDev, собираем требования с клиентов, пишем техническое задание
Опросите конечных пользователей, чтобы выявить их потребности и получить максимально реалистичный прототип продукта. Такое исследование нужно провести «на берегу», до начала рабочих действий по проекту, чтобы конечный продукт был жизнеспособен и чтобы сделать продукт под запрос, а не наоборот.
Уделите внимание техническому заданию. ТЗ – гарант, что вы не потратите время зря, не переплатите и получите нужный результат. Кроме того, оно обеспечивает техническое развитие продукта и поможет:
- оценить задачу по бюджету, срокам и объему человеко-часов;
- упростить сдачу-приемку проекта;
- объяснить специалисту, как устроена работа проекта и какую документацию нужно готовить «на выходе».
4. Обеспечиваем команду техническими инструментами
За настройку технической инфраструктуры отвечает системный администратор. Строить боевую инфраструктуру сразу не обязательно – выполните минимальную часть, чтобы обеспечить команде место для работы.
Настройте:
- репозиторий для кодовой базы проекта;
- общие инструменты организации процесса разработки, если они нужны – например, таск-трекер (Jira, Redmine, Trello и другие);
- рабочее окружение: сервисы и приложения, от которых будет зависеть ваш продукт (например, Swagger для документации API).
Убедитесь, что у всех членов команды имеется доступ к инструментам разработки и рабочему окружению.
Задача сисадмина – предоставить стабильную и актуальную платформу для разработки проекта, настроить боевое окружение и обеспечить его поддержку.
Учитывайте, в каких условиях будет работать продукт. Среда разработки должна быть максимально приближена к боевой.
Читайте также:
Разработка мобильного приложения: как создать прототип и зачем нужен MVP
Кроссплатформенная и нативная разработка мобильных приложений в 2021 году
12 шагов к успешному запуску детского приложения
5. Планируем работу команды
Постройте график реализации проекта, по которому будет работать вся команда. Распишите сроки по каждой задаче и определите финальную дату готовности проекта.
Составляя график, учитывайте сдвиг сроков задач (например, увеличение сроков из-за исправлений ошибок) и продумайте, как одна задача зависит от другой.
Например, нет смысла разрабатывать оформление заказа, пока не разработаешь корзину или каталог. Тестировщик не сможет проверить задачу, пока не положит товар в корзину. Лучше делегировать эту задачу одному человеку, чтобы он делал корзину, а затем оформление.
Здесь же декомпозируйте по задачам техническое задание. Разбейте его на небольшие задачи и распределите трудовые ресурсы так, чтобы каждый сотрудник был полностью загружен задачами.
Постарайтесь избавиться от крупных задач — их сложно оценивать, контролировать, тестировать и запускать в релиз. В таких задачах гораздо чаще встречаются ошибки после релиза в боевую среду. Если задача занимает более 20-человека-часов — декомпозируйте ее на мелкие, иначе она рискует превратиться в «болото».
6. Делегируем задачи, контролируем их выполнение
Делегирование — задача тимлида, который соотносит сложность задачи с уровнем специалистов. Он не отдаст младшему специалисту задачи, которые ему «не по зубам», или обеспечит поддержку, которая позволит ему выполнить задачи правильно.
Убедитесь, что разработчик верно понял задачу. Перед стартом соберите команду вместе и обговорите все этапы работы: каждый должен понимать, что делает команда в целом и какова его роль в этом процессе.
На протяжении всего процесса разработки тимлид помогает членам команды в решении сложных технических вопросов и держит в фокусе общую картину проекта. Он учитывает ее, чтобы принимать решения о последовательности задач и распределении трудовых ресурсов.
Контролируйте сроки — например, можно проводить ежедневные или еженедельные встречи с командой. Это поможет держать руку на пульсе, следить за этапами реализации проекта и вовремя решать возникающие сложности.
Неважно, какую методологию ведения проекта вы выбрали — гибкую или классическую. Следите за сроками: работа над проектом часто превращается в рутину, где легко зациклиться на мелких задачах. Не засыпайте! Отсекайте лишнюю работу, проверяйте задачи и сводите их в единое целое, чтобы адекватно оценить готовность проекта.
7. Выкладываем, тестируем и дорабатываем продукт
Тестирование каждой задачи повышает качество продукта и бережет вас от дефектного релиза с ошибками. Не забудьте про код-ревью — проверку кода, который написал разработчик. Обычно ревью проводит тимлид проекта или кто-то из старших разработчиков. Если возникают спорные моменты, привлекайте автора кода.
Перед выкладкой проведите пусконаладочные работы. Это финальный этап разработки перед запуском: продукт готовят к работе в боевой среде, и команда настраивает боевую инфраструктуру. Не забудьте про системы логирования, резервного копирования и прочие системы выявления сбоев и устранения их последствий.
После этого продукт выкатывается в боевую среду, его финально проверяют тестировщики.
Цифровой продукт нельзя сделать раз и навсегда. Поддерживайте его работу, чтобы он оставался актуальным и полезным для пользователей.
Помните, что завершенных проектов не бывает. Ошибки находят даже после выпуска продукта. Следите за ним даже после успешного выпуска и вовремя исправляйте дефекты.
Чтобы организовать процесс разработки, который будет работать без вашего участия:
- Отталкивайтесь от методологии: она определит, как, в каком составе и в какие сроки вы будете работать;
- Создайте команду специалистов и определите роль каждого: на самостоятельную команду можно положиться, ведь она сама принимает решения;
- Не работайте вслепую: отталкивайтесь от запросов клиентов и создайте понятное, ясное и четкое техническое задание;
- Обеспечьте рабочее пространство: для разработчиков это не только кресло, стол, кофе и печеньки, а репозиторий, технические инструменты и рабочее окружение;
- Составьте график реализации проекта: разбивайте большие задачи на мелкие и следите, чтобы рабочий процесс был логичен, а разработчики не сидели без дела;
- Назначьте ответственного по каждой задаче и контролируйте срок ее выполнения: так вам не придется удивлять разработчиков их «новыми» обязанностями спустя месяц со старта, и вы не затянете процесс даже при гибкой методологии;
Следите за продуктом даже после релиза: в IT-индустрии ни одно решение не будет работать вечно. Обновляйте модули, добавляйте новые технологии и инструменты, чтобы продукт всегда был актуальным.
Фото: Joyseulay / Shutterstock
|
Разработка ПО: пример бизнес-процесса из практики
Разделяя важность методологии как основы для реальных бизнес-процессов, следует отметить разницу в понятиях методология и бизнес-процесс. Бизнес-процесс представляет из себя реализацию методологии, ее отдельных элементов или элементов нескольких методологий в конкретной организации при выполнении конкретных проектов и создании конкретных продуктов. Поэтому, создание бизнес-процесса разработки ПО на основе одной из существующих методологий является первой и важнейшей задачей компании, желающей заняться в том или ином виде созданием софта (для внешних заказчиков или своих внутренних нужд). Как показывает опыт автора, вполне возможно создать небольшую группу разработки и начать делать софт и без четкого описания бизнес-процесса. Однако, когда число участников такой «неформальной» команды становится больше пяти человек, то потери от отсутствия четкого регламента становятся несопоставимо большими по сравнению с затратами на регламентацию бизнес-процесса и специализированное ПО для его автоматизации. Потери в данном случае могут быть как прямыми (например, бесконечные переделки одной и той же функциональности по причине несоответствия требованиям заказчика), так и косвенными (например, ухудшение психологической атмосферы в коллективе, связанное с непониманием зоны своей ответственности каждым участником команды). В данной статье приводится пример бизнес-процесса разработки ПО, созданный автором на основе элементов нескольких методологий (наибольшее количество элементов взято из MSF) и собственного многолетнего опыта разработки и управления разработкой ПО. Данный бизнес-процесс ориентирован на ведение крупных проектов по разработке ПО на достаточно «зрелой» стадии, когда продукт уже может эксплуатироваться заказчиками и когда речь уже идет скорее о развитии и доработках функционала, а также устранении «багов», нежели о разработке «с нуля» небольших программных продуктов. СодержаниеРолевая модель
Один специалист может выполнять несколько ролей, но с учетом определенных ограничений. Допускаются следующие сочетания ролей одним человеком.
Схема бизнес-процессаОсновная схема бизнес-процесса приведена ниже. В ней принимают участие члены проектной команды согласно ролевой модели. Бизнес-процесс включает в себя пять групп (контуров) работ:
Контур сбора требованийОсновной операцией в данном случае является процедура регистрации требований на доработку. Под требованием понимается в данном случае любое формально описанное условие, которому должно удовлетворять создаваемое решение. В частности, требованиями являются:
Требования могут поступать из различных источников, например:
Все требования хранятся в Репозитории требований. Подробнее о требованиях (их атрибутах и жизненном цикле) написано в разделе «Информационная модель». Зарегистрировать требование может любой участник проектной команды, заполнив необходимый набор полей. В дальнейшем все активности по разработке связываются с конкретными требованиями, на реализацию которых они направлены. После регистрации требования выясняются основания для его реализации (ТЗ, договора и т.д.). Если оснований не обнаруживается, то требование отвергается или инициируется процесс внесения дополнений в договорные документы. Если основания есть, то требование может быть использовано в других контурах работ. Также требование может быть уточнено, если из его описания не понятно имеет оно основания или нет. Все требования делятся на две группы с точки зрения подхода к их реализации:
Решение о реализации мелких доработок принимается руководителем группы путем назначения требования на соответствующего разработчика (Контур небольших доработок). Реализация средних и крупных доработок происходит постадийно:
Контур среднесрочного планированияВ рамках контура сбора требований членами проектной команды путем проведения совещания принимается решение о реализации имеющих основания требований. Производится их приоритезация и решается, в какую именно версию должны попасть требования в зависимости от их приоритета. Распределение требований происходит по нескольким следующим версиям с временным интервалом до полугода. В итоге составляется среднесрочный план, представляющий из себя список требований, которые планируется реализовать в следующих версиях. В карточке каждого запланированного требования помечается эта версия. На основании среднесрочного плана по реализации требований производится детальное планирование аналитических работ по написанию ТП с постановкой задачи по их реализации. Планы работ хранятся в Репозитории задач. Контур аналитических работСогласно плану работ Аналитик производит аналитическую проработку требования и составляет документ с утвержденной структурой разделов – Технический проект с описанием логики реализации требования. Технический проект, подготовленный Аналитиком, согласуется с:
После составления и согласования ТП требование помечается как готовое к включению в план разработки версии. Технический проект, как и остальная документация хранится в Репозитории документации. Контур разработки версииКонтур разработки версии представляет из себя одну итерацию разработки: от планирования работ по версии, до ее выпуска. После выпуска одной версии, начинаются работ по следующей версии. При планировании работ по версии проектная команда просматривает требования, выбирая среди них те, которые:
Также в состав работ по версии могут включаться требования, имеющие критичную важность и наивысший приоритет. В этом случае их аналитическая проработка планируется в рамках работ по версии. Однако это вариант не является основным. После выделения требований, подлежащих разработке в рамках настоящей версии, составляется детальный план разработки этой версии, включающий в себя все виды работ. Затем согласно плану Разработчик совместно с Архитектором (в части концептуальных архитектурных решений) на основании Технического проекта пишет Рабочий проект, в котором описывает реализацию соответствующего требования. Рабочий проект, подготовленный Разработчиком, согласуется с:
После согласования рабочего проекта Разработчик приступает к его реализации, а Архитектор обновляет архитектурную модель решения в соответствии с Рабочим проектом. Для достаточно крупных требований функционал в рамках одного требования (и, соответственно, Рабочего проекта) реализуется несколькими частями. После разработки одной части происходит ее автоматическое тестирование и проверка качества кода Архитектором. Если выявляются недочеты – Разработчик их устраняет. После реализации всех частей одного требования Разработчик демонстрирует разработанный функционал Аналитику – происходит его концептуальное тестирование, т.е. тестирование на предмет соответствия потребностям пользователей. Если выявляются несоответствия потребностям пользователей, то происходит либо доработка Рабочего проекта и, затем, реализованного функционала либо сразу доработка функционала (в случае мелких замечаний, не требующих изменения Рабочего проекта и архитектурной модели). В случае успешного концептуального тестирования Разработчик приступает к реализации следующего требования в соответствии с планом работ по версии. Также после согласования новой функциональности Аналитик обновляет пользовательскую документацию на решение. После того, как все доработки, запланированные в версии, реализованы Билд-инженер производит сборку версии. Билд-инженер, формирует Сопроводительный документ к версии, в котором:
Собранная версия тестируется Тестером при участии Аналитика согласно плану тестирования, являющегося составной частью Технического проекта, разработанного Аналитиком. Выявленные ошибки регистрируются в Репозитории требований в виде требований с типом «Ошибка тестирования версии». Выявленные ошибки устраняются Разрабочтиками, которые реализовывали соответствующий функционал, при необходимости модифицируется Рабочий проект и Архитектурная модель. После того, как ошибки тестирования версии устранены тестирование повторяется. Версия выпускается в следующих случаях:
После того как принято решение о выпуске версии Билд-инженер готовит дистрибутивы и Сопроводительный документ (актуализирует его при необходимости) и передает его для развертывания. После выпуска версии работы в рамках данной итерации считаются завершенными и начинается работа над следующей версией. Контур небольших доработокНебольшие доработки – доработки с длительностью реализации менее человеко-дня, не требующие написания Технического проекта и Рабочего проекта. Все небольшие доработки делятся на две группы:
Решение о реализации мелкой доработки с нормальным приоритетом принимается Руководителем группы путем анализа загрузки разработчиков по группе. Наименее загруженные на реализации плановых доработок по версии Разработчики занимаются устранением мелких доработок с нормальным приоритетом. После устранения мелких доработок с нормальным приоритетом они попадают в рабочую базу кода и выпускаются со следующей основной версией. Решение о реализации мелкой доработки с критическим приоритетом принимается Руководителем проекта совместно с Руководителем группы. В этом случае Разработчик, наиболее хорошо знакомый с возникшей проблемой может быть временно переключен с плановых работ на ее устранение. После устранения критических мелких доработок (одной или нескольких сразу) инициируется процедура выпуска промежуточной версии. Сборку осуществляет Билд-инженер, также он готовит Сопроводительный документ в котором указывает какой номер данной промежуточной версии и перечень критических мелких доработок устраненных в ней. После выпуска промежуточной версии Разработчики вносят изменения, соответствующие критическим мелким доработкам, в основную рабочую версию. Участие ролей в операциях бизнес-процессаОдно из основных требований к бизнес-процессу разработки – равномерная загрузка всех членов проектной команды на всем протяжении разработки с учетом ее итеративного и последовательного (ТП, РП, реализация и т.д.) характера. На схеме ниже в качестве примера приведено распределение работ при разработке версии с длительностью 8 недель. Рассмотрена вся проектная команда, задействованная во всех контурах работ.
Ключевым элементом данного бизнес-процесса, проиллюстрированным на схеме, является независимое выполнение аналитических работ (Технический проект) и работ по разработке версии (Рабочий проект и реализация) друг от друга с целью обеспечения равномерной загрузки Аналитика на всей итерации разработки. Также важным моментом является участие Разработчика, как в плановых работах по версии, так и в устранении мелких, в т.ч. высоко критичных замечаний. Тестер на ранних стадиях итерации занимается тестированием предыдущей версии и регистрирует обнаруженные ошибки в Репозитории требований, позднее по мере готовности версии он переключается целиком на тестирование текущей версии. Билд-инженер имеет невысокую загрузку на большей части итерации, поэтому, целесообразно совмещение этой роли с одной из следующих ролей: Разработчик, Руководитель группы, Архитектор. Важнейшей задачей Архитектора помимо участия в написании Рабочих проектов и контроля технической стороны проведения разработки является также ведение Репозитория архитектуры – обновления его по мере разработки новой функциональности в соответствии с Рабочими проектами. Руководитель проекта и Руководитель группы помимо задач по управлению проектом и группой соответственно занимаются аналитической работой, особенно концептуальным проектированием решения. Информационная модель бизнес-процессаВсе виды информации в рамках бизнес-процесса разработки распределяются по пяти хранилищам (репозиториям):
Элементы в одном хранилище могут быть связаны с элементами в другом хранилище. Например, требования в репозитории требований могут быть связаны с компонентами из репозитория архитектуры, которыми они реализуются. На схеме ниже показаны примеры содержимого репозиториев и взаимосвязи между ними. Затем в таблице дается краткое пояснение по содержимому репозиториев и описаны взаимосвязи между их элементами.
Средства автоматизации бизнес-процесса
|
В индустрии разработки программного обеспечения (ПО) существуют много различных методологий разработки, которые представляют из себя достаточно концептуальные видения того, как следует реализовывать проекты по созданию ПО. В качестве примеров таких методологий можно привести: Rational Unified Process (RUP), Microsoft Solution Framework (MSF), Extreme Programming (XP), Agile, Capability Maturity Model Integration (CMMI) и многие другие.
Важным этапов создания собственного бизнеса есть тщательное планирование. Составление перечня приблизительных, но максимально приближенных к реальности, сумм расходов и доходов позволяет спрогнозировать целесообразность основания собственного дела.
Любая сфера предпринимательства требует скрупулезной финансовой организации и маркетингового анализа. Сегодня мы обсудим, как следует организовывать бизнес план компании по разработке программного обеспечения.
Так как спрогнозировать точные финансовые потребности предприятия в сфере IT без привязки к конкретному месту и характеристики разрабатываемого продукта весьма трудно, мы очертим статьи расходов крайне обобщенно.
Бизнес план: разработка программного обеспечения
Если вы с группой единомышленников интересуетесь компьютерами и пишите программы ради интереса — это хобби. А вот если вы уже планируете продавать свою продукцию и сотрудничать с другими компаниями — это предпринимательство.
Чтобы получить признание на рынке и честно выплачивать налоги государству необходимо зарегистрировать свою деятельность. Иначе с вами не захотят серьезно сотрудничать. Для этого достаточно пройти регистрацию в качестве индивидуального предпринимателя и можно приступать к созданию компании.
Регистрация ИП: что нужно и чего ожидать?
| Служба регистрации | Федеральная налоговая служба РФ по месту прописки |
| Необходимые документы | 1. Заявление о регистрации ИП (в 1 экземпляре). Лист Б формы Р21001 должны заполнить в налоговой и отдать вам на руки. 2. Копия идентификационного номера налогоплательщика. 3. Копия паспорта с пропиской на одном листе. 4. Квитанция об оплате государственной пошлины (800 рублей). |
| Длительность | В течении 5-ти дней вас зарегистрируют в качестве ИП или же сообщат об отказе |
| Подтверждающие документы | 1. Свидетельство о государственной регистрации физического лица в качестве индивидуального предпринимателя (ОГРН ИП). 2. Выписка из единого государственного реестра индивидуальных предпринимателей (ЕГРИП). |
| Действия после регистрации | Необходимо стать на учёт в пенсионный фонд и федеральный фонд обязательного медицинского страхования (ТФОМС), получить коды статистики. Также можно, но не обязательно, открыть расчетный счет в банке, изготовить печать для предприятия, зарегистрировать контрольно-кассовый автомат и пройти регистрацию в Роспотребнадзоре. |
| Платежи | • Налог в пенсионный фонд: 36 238 руб./год + 1% от сумм дохода свыше 300 000 рублей • Налог на доход физических лиц • Страховые взносы |
| Закрытие ИП | Происходит только в следующих случаях: 1. По решению ИП о прекращении деятельности. 2. В связи со смертью ИП. 3. По решению суда в принудительном порядке. 4. В связи с вступлением в силу приговора суда о лишении прав заниматься предпринимательской деятельностью. 5. В связи с аннулированием (прострочкой) документа, подтверждающего право данного лица проживать на территории РФ. 6. В связи с принятием судом решения о признании ИП несостоятельным (банкротом). |
Сразу после регистрации, а лучше — параллельно с ней, следует тщательно продумать бизнес план компании по разработке программного обеспечения. При этом функция плана состоит не исключительно в финансовом планировании, он также определяет цели компании, задания штатных сотрудников, предусматривает возможные риски ведения бизнеса и способы их предотвращения.
Структура и особенности по созданию бизнес плана компании по разработке программного обеспечения
Составление БП требует специального образования в сфере экономики и навыков проведения маркетингового анализа. Если вы никогда ранее не сталкивались с такой задачей, поручите её выполнение профессионалам.
Заказать план развития компании можно у представителей частных фирм, которые специализируются на этом. Некачественный БП может послужить причиной краха вашего предприятия, поэтому не стоит на нём экономить и пренебрегать им.
Стоимость бизнес плана сильно зависит от города, масштаба предприятия и сферы деятельности. Примерно заказ обойдётся в сумму от 15 000 до 30 000 рублей.
Для чего нужен БП помимо результативного планирования вложений капитала? Во-первых, он понадобится предпринимателю при поиске инвесторов или оформлении банковского кредита.
Во-вторых, он необходим для налаживания контактов с потенциальными партнёрами и заказчиками.
В-третьих, он распределяет рабочие обязанности в коллективе и определяет минимально необходимый штат сотрудников для эффективной работы компании.
Бизнес план предприятия по разработке программного обеспечения должен содержать в себе следующие пункты:
- резюме проекта,
- анализ действующего рынка,
- материальные ресурсы,
- организация,
- уплата налогов,
- финансовый план,
- оценка эффективности проекта,
- анализ рисков.
Что нужно расписать в каждом из указанных пунктов?
| Резюме | • Цель проекта: разработка, реализация и сервис программного обеспечения на базе новых информационных технология. • Оценка потребительской ценности планируемой к выпуску продукции и потенциала рынка этой продукции • Прогнозируемые объемы реализации и финансовые результаты • Объемы необходимых инвестиций и сроки возврата средств инвесторам |
| Анализ действующего рынка | • Исследование структуры рынка сбыта программного обеспечения • Анализ динамики потребительского спроса на продукцию • Прогнозирование уровня конкуренции • Разработка маркетинговой стратегии, выбор целевой аудитории, планирование стратегий по расширению клиентской базы • Постановка ценовой политики |
| Материальные ресурсы | • Организация рабочего пространства: расчет расходов на аренду или покупку помещения, проведение ремонтных работ, закупку и установку оборудования • Распределение объема инвестиций по направлениях |
| Организация | • Составление календарного плана реализации проекта • Планирование штатной организационной структуры |
| Уплата налогов | • Расчет налоговых выплат: НДС, налог на прибыль, на имущество, выплаты в пенсионный и страховой фонды |
| Финансовый план | • Предоставление прогнозного отчета о движении средств, о прибылях и убытках предприятия |
| Оценка эффективности проекта | • Анализ безубыточности • Расчет финансовых показателей (рентабельность) • Изучение показателей финансовой эффективности (прогнозного периода, постпрогнозного периода, условий расчета, процентной ставки дисконта) |
| Анализ рисков | • Организационные и управленческие риски (риск срыва сроков разработки и релиза продукта, ошибок в подборе персонала, высоких цен на продукцию) • Отработка мер по снижению или полного исключения риска • Учёт возможных финансовых (недостачи финансирования проекта) и экономических рисков (изменений в системе налогообложения, увеличения ставок налогов) |
Бизнес план предприятия по разработке программного обеспечения: подбор помещения
Для предприятия по разработке ПО достаточно офиса, общей площадью 50-60 кв.м. Более выгодно арендовать помещение, нежели покупать его.
Арендная стоимость офиса необходимых параметров в Москве обойдётся в сумму от 32 тыс. до 50 тыс. рублей в месяц, зависимо от расположения и состояния ремонта. Дополнительные затраты на ремонт помещения составят примерно 6-8 тыс. рублей.
Главное минимально необходимое оборудование — это, конечно же, компьютеры. Для каждого сотрудника в штате нужно организовать самостоятельное рабочее место: личный стол, ПК, оргтехнику для печати и сканирования документов и прочее.
Как создать свою компанию по разработке
программного обеспечения в России?
Закупка мебели и техники для организации офисного пространства
| Категория товара | Изображение | Стоимость за штуку, руб. | Необходимое количество, штук | Общая сумма затрат, руб. |
|---|---|---|---|---|
| Компьютер |  |
27 730 | 6 | 166 380 |
| Монитор |  |
5 240 | 6 | 31 440 |
| Клавиатура |  |
430 | 6 | 2 580 |
| Компьютерная мышь |  |
280 | 6 | 1 680 |
| Колонки |  |
450 | 6 | 2 700 |
| Принтер |  |
11 030 | 6 | 66 180 |
| Рабочий стол |  |
5 190 | 6 | 31 140 |
| Компьютерное кресло |  |
6 290 | 6 | 37 740 |
| Сейф |  |
62 500 | 1 | 62 500 |
| Факс |  |
5 670 | 2 | 11 340 |
| Итого: | 413 680 |
Мы провели расчёт необходимого оборудования на шесть сотрудников. Примерно таким может быть штат небольшой компании по разработке ПО.
Чтобы лучше разобраться в том, как разделяются обязанности между работниками на предприятии, нужно составить список обязательных вакансий и очертить сферу деятельности каждого сотрудника.
| Должность | Рабочие обязанности | Заработная плата в месяц |
|---|---|---|
| Руководитель проекта | o Формирование планов, контроль их выполнения. o Организационная работа, в том числе с заказчиком. o Аналитическая работа. |
От 70 000 руб. |
| Руководитель группы | o Оценка длительности и трудоемкости задач в процессе планирования. o Контроль выполнения планов группой. o Разделение работ внутри группы. o Аналитическая работа. o Организация сбора требований заказчика. o Работа с заказчиком. |
От 58 000 руб. |
| Аналитик | o Сбор требований заказчика. o Разработка технического проекта, проверка его функциональности. o Разработка планов тестирования. o Разработка пользовательской документации. |
От 48 000 руб. |
| Архитектор ПО | o Разработка рабочего проекта, проверка его функциональности. o Контроль качества кода и его соответствие проектным решениям по архитектуре. o Репозиторий информации по архитектуре решений. o Участвует в формировании планов и оценке сложности/длительности задач. o Участвует в комплексном тестировании. |
От 48 000 руб. |
| Разработчик | o Разработка рабочего проекта (при участии архитектора). o Разработка функциональности. o Проверка качества кода, исправление существующих ошибок. o Проведение первичного и комплексного тестирования кода. |
От 65 000 руб. |
| Тестер | o Тестирование функциональности. o Написание Unit текстов. o Участие в разработке планов тестирования. |
От 54 000 руб. |
| Билд-инженер | o Сборка версии. o Подготовка сопроводительных документов. |
От 60 000 руб. |
Как подобрать на работу мотивированных сотрудников в сфере IT?
Специалисты могут выполнять несколько ролей одновременно с условием рациональной нагрузки и выплаты повышенной заработной платы. Например, руководитель проекта, помимо своих центральных должностных обязанностей, может исполнять роль аналитика и тестера.
Как показывает бизнес план — разработка программного обеспечения имеет множество нюансов, в котором человеку из другой сферы деятельности разобраться весьма сложно.
Итак, следует подытожить ключевые моменты. Для запуска собственного предприятия по разработке ПО потребуется минимальная сумма вложений от 1,5 млн. рублей.
Основные статьи расходов на первичном этапе запуска компании — это закупка необходимого оборудования и обустройство рабочего пространства. На более поздних этапах работы предприятия основная часть расходов будет идти на выплату заработной платы сотрудников.
Строк окупаемости колеблется в зависимости от направления деятельности компании и её продуктивности. Но, как минимум, проект окупит себя не ранее, чем через 1,5-2 года активной работы.
Бизнес план компании по разработке программного обеспечения поможет спрогнозировать финансовые расходы, актуальные в вашем регионе, и минимизировать возможные риски на ранних этапах запуска своего дела.
- Твиттер 0
- Facebook 0
- Обсудить
- Вконтакте 0
Полезная статья? Не пропустите новые!
Введите e-mail и получайте новые статьи на почту
Компания, разрабатывающая программное обеспечение
A софтверная компания — это компания, основными продуктами которой являются различные формы программного обеспечения, программные технологии, распространение и разработка программных продуктов. Они составляют индустрию программного обеспечения.
Содержание
- 1 Типы
- 2 Общие роли в компании-разработчике программного обеспечения
- 3 Структура
- 4 Методологии
- 5 Жизненный цикл продукта
- 6 Системы и процедуры
- 6.1 Бизнес-аналитики
- 6.2 Программисты
- 6.3 Тестировщики
- 6.4 Менеджеры проектов / продуктов
- 7 Аудиты эффективности
- 8 См. также
- 9 Ссылки
Типы
Существует несколько различных типов компаний-разработчиков программного обеспечения:
- Крупные и известные компании, производящие готовые коммерческие продукты (COTS), такие как Microsoft, SAP AG, Oracle Corporation, HP, Adobe Systems и Red Hat
- Мелкие компании, которые производят индивидуальное программное обеспечение для другие компании и предприниматели
- Компании, производящие специализированное коммерческое готовое программное обеспечение, такое как Panorama, Hyperion и Siebel Systems
- Компании, производящие программное обеспечение как услуга SaaS, например Google, Facebook и LinkedIn
- Компании pr производство программных компонентов, таких как Dundas
- Application Service Provider, например Salesforce
- Компании, производящие программное обеспечение на заказ для вертикальных отраслей или определенного географического региона регионы
- Независимые поставщики программного обеспечения (ISV), которые создают, разрабатывают и продают потребительское или корпоративное программное обеспечение, которое используется конечными пользователями
Все они могут быть отнесены к одной или многие из следующего:
- договорный — когда компания-разработчик программного обеспечения получает контракт на поставку определенного программного обеспечения извне (программное обеспечение аутсорсинг )
- разработка продукта — когда она производит готовое к использованию упакованное программное обеспечение; Готовый коммерческий продукт
Общие роли в компании-разработчике программного обеспечения
Организация компании по разработке программного обеспечения — это очень специализированный вид управленческих навыков, при котором опытные люди могут изменить организационные проблема в уникальное преимущество. Например, если подгруппы расположены в разных часовых поясах, может быть обеспечен 24-часовой рабочий день компании, если команды, системы и процедуры хорошо отработаны. Хорошим примером является группа тестирования, работающая в часовом поясе на 8 часов вперед или назад группа разработчиков, которая исправляет программные ошибки, обнаруженные тестировщиками.
Профессиональная компания-разработчик программного обеспечения обычно состоит как минимум из трех специализированных подгрупп:
- бизнес-аналитиков, которые определяют бизнес-потребности рынка
- Разработчики программного обеспечения, которые создают техническую спецификацию и напишите программное обеспечение
- Тестировщики программного обеспечения, которые несут ответственность за весь процесс управления качеством
В более крупных компаниях-разработчиках программного обеспечения используется более высокая специализация, и довольно часто :
- Технические писатели, которые пишут всю документацию, такую как руководства пользователя
- Специалисты по выпуску, которые отвечают за сборку всего продукта и контроль версий программного обеспечения
- Пользователь опытные дизайнеры, которые создают архитектуру дизайна на основе бизнес-требований, исследований пользователей и опыта юзабилити
- Графические дизайнеры, которые обычно отвечают за дизайн графического пользовательского интерфейса.
- Инженеры по техническому обслуживанию, которые стоят за двумя, тремя или более линиями поддержки
- Con Султанты несут ответственность за приведение решения в действие, особенно если необходимы некоторые специальные знания. Примеры этого включают: встраивание программного обеспечения бизнес-аналитики, интеграцию с существующими решениями и реализацию бизнес-сценариев в программном обеспечении Business Process Management.
Структура
Менеджер компании-разработчика программного обеспечения обычно называют главой разработки (HOD) и отчитывается перед заинтересованными сторонами. Он или она возглавляет подгруппы напрямую или через менеджеров / лидеров в зависимости от размера организации. Обычно наиболее оперативными являются бригады до 10 человек. В более крупных организациях, как правило, существуют две модели иерархии:
Типичная структура компании-разработчика программного обеспечения
Все команды полностью независимы и работают над разными проектами отдельно. Структура довольно проста, и все сотрудники подчиняются одному человеку, что делает ситуацию достаточно ясной, однако это не лучшее решение с точки зрения обмена знаниями и оптимального использования человеческих ресурсов.
Матричная структура
В этой модели есть выделенные менеджеры / лидеры для каждой основной специализации, «арендующие» своих людей для конкретных проектов, возглавляемых менеджерами продуктов / проектов, которые формально или неформально покупают людей и платят за их время. Это приводит к тому, что у каждого частного сотрудника есть два начальника — менеджер по продукту / проекту и специализированный менеджер по ресурсам. С одной стороны, это оптимизирует использование человеческих ресурсов, с другой — может вызвать конфликты по поводу того, какой из менеджеров имеет приоритет в структуре.
Существует также ряд вариантов этих структур, и ряд организаций имеют эту структуру, распределенную по различным отделам и подразделениям.
Методологии
Компании-разработчики программного обеспечения могут использовать ряд различных методологий для создания кода. Сюда могут входить:
- водопадная модель, включая методологии управления проектами, такие как PRINCE2 или PMBoK
- гибкая разработка программного обеспечения, например Extreme Программирование и SCRUM
Существуют также некоторые методологии, которые объединяют оба, например, спиральная модель, Rational Unified Process (RUP) или MSF..
Жизненный цикл продукта
Независимо от используемой методологии, жизненный цикл продукта всегда состоит как минимум из трех этапов:
- Дизайн — включая бизнес-спецификацию и техническую спецификацию
- C — сама разработка
- Тестирование — управление качеством
Каждый этап в идеале занимает 30% общего времени, а оставшиеся 10% остаются в резерве.
UML диаграмма последовательности взаимодействия между этими группами может выглядеть так:
Общее взаимодействие между четырьмя основными группами
На каждом этапе разные group играет ключевую роль, однако каждый тип ролей должен быть задействован на протяжении всего процесса разработки:
- Аналитики после завершения бизнес-спецификации управляют изменяющейся бизнес-ситуацией, чтобы минимизировать возможность изменений с течением времени. Они также поддерживают как программистов, так и тестировщиков на протяжении всего процесса разработки, чтобы гарантировать, что конечный продукт соответствует бизнес-потребностям, указанным в начале. В идеале этот процесс делает бизнес-аналитиков ключевыми игроками во время окончательной доставки решения заказчику, поскольку они лучше всего подходят для обеспечения наилучшего бизнес-уровня.
- Программисты составляют техническую спецификацию на этапе проектирования, то есть почему их называют программистами / дизайнерами и во время тестирования они исправляют ошибки.
- Тестировщики завершают сценарии тестирования на этапе проектирования и оценивают их на этапе кодирования
Системы и процедуры
компании-разработчики программного обеспечения обладают различными системами и процедурами, которые внедрены и работают внутри всех подгрупп. К ним относятся:
Бизнес-аналитики
- Инструменты моделирования, такие как Sparx Systems Enterprise Architect или IBM Rational Rose
Программисты
- Системы контроля версий и версии программного обеспечения процедуры
- Инструменты анализа кода и стандарты кодирования, проверены вручную или автоматически
- Механизмы развертывания
Тестировщики
- Системы отслеживания ошибок
- Автоматизация тестирования инструменты
- Инструменты производительности и стресс-тестирования
Менеджеры проектов / продуктов
- Управление корпоративными проектами (EPM) системы и процедуры
- Управление портфелем продуктов (PPM)
- Управление изменениями системы и процедуры
Есть также Управление жизненным циклом приложений (ALM), которые объединяют некоторые из этих функций в одном пакете и используются во всех группах. Они поставляются различными поставщиками, такими как Borland, ECM или Compuware.
Аудит эффективности
Хорошо зарекомендовавшие себя компании-разработчики программного обеспечения обычно имеют какой-то способ измерения собственной эффективности. Обычно это делается путем определения набора ключевых показателей эффективности (KPI), таких как
- Среднее количество ошибок, совершаемых разработчиком за единицу времени, или строк исходного кода
- Количество ошибок, обнаруженных тестером за цикл тестирования
- Среднее количество циклов тестирования до Zero Bug Bounce (ZBB)
- Среднее время цикла тестирования
- Расчетное время выполнения задачи по сравнению с реальным временем выполнения задачи (точность планирования)
- Количество корректировок к исходному уровню
Ряд организаций ориентированы на достижение оптимального уровня Модель зрелости возможностей (CMM), где «оптимальный» не обязательно означает наивысший. Существуют также другие системы, такие как SEMA Университета Карнеги-Меллона или отдельные стандарты ISO. Небольшие софтверные компании иногда используют менее формализованные подходы. Каждая организация вырабатывает свой собственный стиль, который находится где-то между тотальной технократией (где все определяется числами) и тотальной анархией (где чисел вообще нет). Каким бы путем ни пошла организация, они рассматривают пирамиду, описывающую стоимость и риск внесения изменений в уже начатые процессы разработки:
пирамида, показывающая риск и временные затраты на изменение
См. Также
- Список крупнейших компаний-разработчиков программного обеспечения
Ссылки
- ^«Что такое компания-разработчик программного обеспечения сегодня?». RedMonk. 2014. Получено 2 июня 2017 г.
- ^Независимый поставщик программного обеспечения — что такое ISV? 10duke.com
- ^Процесс разработки программного обеспечения: принципы, методология и технология Автор: Жан Клод Дерниям, Бадара Али Каба, Дэвид Уастелл стр.166
- ^Greenlit: разработка телевизионных идей, основанных на фактах и реальности, от концепции до презентации стр.12
- ^Управление успешными проектами с помощью PRINCE2
- ^Руководство пользователя к PMBOK Guide
- ^Планирование экстремального программирования
- ^Agile Project Управление с помощью Scrum
- ^Упрощение рационального унифицированного процесса: практическое руководство по RUP
- ^Microsoft Solutions Framework (MSF): карманное руководство