Я понимаю, что здесь вряд ли найдутся, специалисты, которые занимались внедрением бизнес-процесса “Создание сайта”. Но я уверен, что у многих есть опыт со стороны заказчиков по созданию сайтов, Ваших компаний. Буду очень благодарен, если Вы поделитесь со мной, Вашим виденье по этим трём вопросам:
1. На Ваш взгляд, с точки зрения бизнес-процессов, “Создание сайта” – где и с чего начинается, когда и чем заканчивается?
2. Какие бизнес-процессы (этапы или виды работ, кому как удобнее) туда входят?
3. Какие работы должны выполнять подрядчики, а какие должны делаться внутри компании заказчика и кем?
Лично, я считаю, что это одни из самых важных вопросов, которым к сожалению руководство компаний не придают должного внимания. А они напрямую влияют на эффективность и полезность Интернета для бизнеса.
Расскажите коллегам:
Оценить : 0
Комментарии
+287 Анатолий Юмашев Системный администратор, Тюмень 24 июня 2009, 19:29
Евгений, добрый день!
советую посмотреть аналогичную модель бизнес процесса http://www.businessstudio.ru/navigator/InTechProekt/b00bef60-163f-4581-8491-e5020b9c6b1b.htm
там можно увидеть и начало и окончание с точки зрения бизнес-моделирования.
только кажется мне, что Вас интересует не бизнес процесс, а технология.
т.е. пример: у нас есть «Технология создания системы электронного документооборота». Это документ в котором собрана вся информация и опыт, методы и требования по созданию системы. в т.ч. позволяет выделять часть проекта для передачи на исполнение заказчику своими силами.
+160 Сергей Лифанов Директор по маркетингу, Украина 24 июня 2009, 19:30
Как не выбросить деньги «на ветер», запуская новое или оптимизируя бизнес существующего web- проекта/издания, и научить его зарабатывать
Я для своих отношений с заказчиками изобрел такую вот «матрицу». Ее можно модифицировать, уточнять подходящими словами. Однако суть интернет-маркетинга не меняется)):
• Общий стратегический анализ внешней и внутренней среды (рынки, конкуренты, опыт, практика, потребители, компания)
• Разработка стратегии развития бизнеса
• Разработка бизнес-плана
• Разработка программ развития бизнеса (управление, контент, сервисы, производство, продвижение, офис, персонал, финансы, продажи)
• Разработка системы управления развитием бизнеса (контроль и мотивация)
+1826 Евгений Корнев Председатель совета директоров, Москва 25 июня 2009, 16:53
Сергей Лифанов, -солидный «докУмент», но его лучше назвать пошаговый алгоритм, для матрицы он тяжеловат, такую матрицу построить трудновато будет 😀 😀
+346 Михаил Альперович Управляющий директор, Украина 25 июня 2009, 17:49
Внедрение бизнес-процесса «создание сайта»?
Внедряем — значит не на один раз?
Не на один раз, значит не себе, значит речь о сайтостроительстве, сайт — суть произведенный для заказчика продукт?
Если речь о моделировании, то нет методической разницы между проектированием бизнес-процесса «создание сайта» и «создание бутылки кефира».
Если речь о внедрении, то нет методической разницы между внедрением бизнес-процесса «создание сайта» и «создание бутылки кефира»
+308 Евгений Лернер CIO, Москва 29 июня 2009, 20:49
Спасибо за ответы. Особенно Лифанову Сергею, честно говоря, не думал увидеть такое подробное описание. Интересно на каких проектах, это применяли полностью? Сколько по времени и сколько по стоимости?
Попробую, чуть подробнее описать смысл моих вопросов: В нашей компании есть внедрённый бизнес процесс создания сайта, в упрощённом варианте ( в 2007 году) он выглядит так Пример детализации бизнес-процесса Создание сайта, красным отмечены этапы которые должен делать заказчик. НО, этот процесс начинается, после заключения договора с заказчиком и получение предоплаты.
Как правило, к разработчикам приходит клиент, у которого своими силами проработаны все цели и постановка задачи. У кого-то это ТЗ разной степени проработки, кто-то вообще на словах, короче у всех по разному. И это называется постановкой задачи разработчику, на основании который он должен назвать сроки и стоимость.
Ни кто из разработчиков, глядя на эти документы (постановку задачи) особо не утруждается. Они не хотят бесплатно заниматься выяснением необходимости и целесообразности всего чего хотят сделать заказчик, а подавляющие большинство, включая очень известные компании и не в состояние это сделать.
Сейчас никто, даже очень крупные компании, не прорабатываю детально свою стратегию присутствия в Интернете. Кто за что отвечает внутри компании? Какая информация, кем и как она будет создаваться и попадать в Интернет? И многие другие вопросы. В этом я вижу одну из самых главных проблем неэффективности Интернета для коммерческих организаций.
Поэтому я и задал эти вопросы: 1. На Ваш взгляд, с точки зрения бизнес-процессов, “Создание сайта” – где и с чего начинается, когда и чем заканчивается? 3. Какие работы должны выполнять подрядчики, а какие должны делаться внутри компании заказчика и кем?
+4100 Виталий Елиферов Менеджер, Москва 01 июля 2009, 10:59
Ремарка: 1. Создание сайта — проект с заданной датой, затратами ресурсов и результатом. 2. Эксплуатация сайта — процесс поддержания, наполнения, редактирования, модерирования и т.д. Разные цели, задачи и даже, могут быть разные исполнители. С уважением Виталий.
+308 Евгений Лернер CIO, Москва 01 июля 2009, 14:04
Виталий Елиферов пишет: 1. Создание сайта — проект с заданной датой, затратами ресурсов и результатом. 2. Эксплуатация сайта — процесс поддержания, наполнения, редактирования, модерирования и т.д. Разные цели, задачи и даже, могут быть разные исполнители.
Виталий, здорово, я именно об этом и хотел говорить. Как говорится почувствуйте разницу: 1. Цель — создать сайт за 3 месяца. 2. Цель — создать сайт, на котором через год будет среднея посещаемость 1000 целевых пользователей в день. 3. Цель — создать сайт, через год выйти на продажи в 3 млн. руб. в месяц. Представляете как цель меняет подход ко всем работам, разработку бизнес-плана, концепцию, сами бизнес- процессы, исполнителей, ответственность и многое другое.
+4100 Виталий Елиферов Менеджер, Москва 01 июля 2009, 15:25
Виталий, здорово, я именно об этом и хотел говорить. Как говорится почувствуйте разницу: 1. Цель — создать сайт за 3 месяца. 2. Цель — создать сайт, на котором через год будет среднея посещаемость 1000 целевых пользователей в день. 3. Цель — создать сайт, через год выйти на продажи в 3 млн. руб. в месяц. Представляете как цель меняет подход ко всем работам, разработку бизнес-плана, концепцию, сами бизнес- процессы, исполнителей, ответственность и многое другое.
Добрый день, Евгений! Вполне представляю, поэтому и написал. 😀 Есть старые банальные примеры: Взяли несколько сотен выпускников какого-то бизнес-колледжа. Итог анализа: В колледже только 5% из них имели сформулированные свои цели. Через несколько лет после выпуска эти 5% «стоили» больше, чем другие 95%. C уважением Виталий.
P.S. Кстати, мне кажется, что мы пересекались лет 6-7 назад. 😉
+157 Ольга Русакович Нач. отдела, зам. руководителя, Москва 02 июля 2009, 18:37
Евгений Лернер пишет: Сейчас никто, даже очень крупные компании, не прорабатываю детально свою стратегию присутствия в Интернете. Кто за что отвечает внутри компании? Какая информация, кем и как она будет создаваться и попадать в Интернет? И многие другие вопросы.
Соглашусь с тем, что эта проблема существует, причем повсеместно. При этом некоторые заказчики (включая очень крупные компании) предполагают, что проработка стратегии не просто лежит на разработчике, но проработать ее он должен во всех деталях задолго до заключения договора и принятия решения о сотрудничестве на этапе составления ком. предложения («безвозмездно, то есть даром», как говорила Сова).
Многие клиенты, не боясь показаться некомпетентными, открыто говорят, что разработчик, который видит их отдельно взятый бизнес первый раз в жизни, обязан гораздо лучше разбираться в стратегиях продвижения этого бизнеса, нежели инсайдер, работающий там несколько лет. Они искренне удивляются, когда им задают вопросы об их бизнесе, а не дают готовые ответы 🙂 И так как часто непонимание со стороны клиента того, какой и для чего им нужен сайт, приводит к задежкам принятия решений о его разработке, мы уже давно взяли за правило включать в коммерческое предложение не только смету, но и наше видение структуры сайта (схема и описание того, почему и для чего нужен каждый раздел).
Иногда это помогает, а иногда наоборот, т.к. клиент требует продолжения банкета, говоря, что структура не достаточно проработана, в ней нет креатива, не отражены все нюансы. Но это только одна сторона медали. Есть еще вторая. На каждый год работы у нас приходится 2-3 клиента (из 40-45), которые по настоящему серьезно и грамотно подходят к сайту.
Всё обдумывают, прорабатывают и т.п., НО когда дело доходит до разработки, созданная система летит в тар-тарары. В прошлом году мы начали проект для ювелирной компании, который должен был стать оптовой торговой площадкой. Из этой задачи вытекали акценты на удобство, быстроту работы, связи со складской системой и т.п.
Со стороны клиента задачи были согласованы по всей цепочке от 1С-программиста до президента. Но в процессе разработки дизайна мы постепенно перешли от удобного интерфейса к конфетно-гламурному варианту с мелким шрифтом, ограниченной контентной областью, огромной интро-флэш-заставкой. Почему?
Потому что просто рекламный отдел и президент передумали и захотели красиво вместо удобно. И наоборот. Другой компании, имевшей вполне конкретную цель разработки маленького красивого сайта к 10-ти летию из 3-х страниц, для каждой из которых заранее были утверждены тексты и фотографии, неожиданно потребовался каталог на 10 тысяч товаров и интернет-магазин.
Это произошло не потому что в процессе согласования кого-то забыли спросить или сменились люди, а просто это пришло в голову по ходу. 10-ти летие заказчика состоялось 2 недели назад, а сайт не принят из-за того, что стороны занимаются согласование того, как теперь решать проблему изменившейся задачи. Отсюда вытекает неутешительный вопрос. А помогает ли обдумывание стратегий присутствия в Интернет на стороне владельца сайта достижению эффективного результата? Или на практике все равно придется двигаться ощупью с некоторым процентом неудач.
+308 Евгений Лернер CIO, Москва 03 июля 2009, 14:49
Ольга Русакович пишет: Отсюда вытекает неутешительный вопрос. А помогает ли обдумывание стратегий присутствия в Интернет на стороне владельца сайта достижению эффективного результата? Или на практике все равно придется двигаться ощупью с некоторым процентом неудач.
Ольга, как любой проект «Создание сайта», подвержен изменениям. Особенно после его запуска и начала работ. Чтобы эти изменения, не были хаотичными и зависели от настроения отдельных участников процесса, нужны чёткие ориентиры. Для того, чтобы проект стал успешным, основными ориентирами должны быть цели, сроки, затраты! Я не случайно большое внимание уделяю целям.
В своём предыдущем сообщение, как пример были показаны три цели. Чем подробнее и детальнее проработана цель (чего хотим достичь в конкретные, временные промежутки, обязательно в цифровых показателях, которые можно и нужно замерять), тем конкретнее будут определены ориентиры И сроки в таком проекте, будут иметь очень высокие приоритеты, гораздо выше, чем кому-то не нравится элемент дизайна, придумали новый функционал или что-то ещё, очень субъективное.
Причём далеко не факт, что эти изменения могут повлиять на достижение цели, но вот сроки они увеличат точно, а скорее всего и затраты. Хороший руководитель проекта, это понимает отлично и прежде чем пойдёт на такие изменения, должен десять раз подумать. Изменение и корректировки в сайте, и планах, нужно делать, когда сайт запущен в работу.
Есть статистика, она анализируется и на основании цифр, принимаются решения о изменениях, улучшениях и т.д. Но если у проекта нет чётких целей, как в первом (часто и во втором случаи), то мы имеем проекты с непонятными ориентирами, в которых может менятся всё в процессе создания, иногда до бесконечности и как правило с сомнительными результатами. Ольга, я обратили внимание на Вашу активность на некоторых тематических и отраслевых площадках. Пользуясь случаем, приглашаю Вас на наш корпоративный блог, я думаю, что Вам будет интересны многие его разделы, особенно этот Директорам и топ-менеджерам. Нам интересно Ваше мнение по профессиональным вопросам. /Отредактировано модератором/
+157 Ольга Русакович Нач. отдела, зам. руководителя, Москва 08 июля 2009, 19:34
Евгений, у меня даже в мыслях не было с Вами спорить о нужности и важности целеполагания. Его жизненная необходимость очевидна. В идеальной ситуации заказчик всегда должен четко понимать что и зачем ему нужно. Именно поэтому так сильно и огорчает, когда из-за ерунды заказчик готов жертвовать и сроками, и деньгами (недавно нам пришлось перенести сроки сдачи с марта на июль из-за того, что все это время мы двигали по главной странице корень женьшеня, причем заказчик не выращивает женьшеня и не торгует им, а поставляет климатическое оборудование, просто это любимое растение директора).
В небольших компаниях с целеполаганием дела обстоят куда лучше, чем в крупных. Т.к. в мелком и среднем бизнесе сайтом напрямую занимается директор или владелец, который максимально хорошо знает, что ему нужно.
А вот в крупных, где для решения концептуальных вопросов созданы целые отделы маркетинга, все обстоит иначе.
В небольшом проценте случаев цели сайта определяет крупное рекламное агентство (если заказчик обслуживается у такого).
В другом небольшом проценте случаев постановка цели обеспечивается руководящим IT-специалистом (особенно, когда речь идет о технически сложном проекте).
Часто IT-директора разбираются не только в технических вопросах, но и в маркетинговых, хорошо понимают клиентов и партнеров своей компании. Что, прочем, неудивительно, ибо IT-директор, как правило, взрослый человек лет 35-ти с хорошим образованием, опытом работы минимум лет 10. Плюс ко всему, он структурно мыслит.
А среднестатистический маркетолог закончил то ли курсы, то ли непонятную академию, имеет опыт работы 2-3 года, мыслит и излагает неконкретно. Поэтому ждать от целого взвода маркетологов серьезного подхода к вопросу не приходится. Причем вряд ли ситуация улучшится в ближайшее время — квалификация сотрудников, отвечающих за цели, не только не растет, но и, такое ощущение, что снижается.
Спасибо за приглашение в блог, обязательно буду заходить 🙂
+362 Максим Беспалов Директор по развитию, Москва 22 июля 2009, 10:20
Хм, позвольте свои три копейки добавить. Строго говоря, интернет сайт, это не есть продукт, который заказывается. Это способ визуализации, дистрибьюции продукта, своеобразный «телевизор», кторый показывает наш продукт — «телепрограмму». Так вот, прежде чем писать план по созданию «бутылки кефира» (респект коллеге, метко сказано) — надо определиться что у нас «кефир» и кому мы собираемся его скармливать. Тогда план работ будет разным по своей сути. На примере гражданской авиации, в которой я немного смыслю — можно составить примерную топологию сайтов:
1. «присутствие» — новости, красота про нас любимых, внутрикорпоративный документооборот, нормативная документация, контакты, форум: максимум красоты при минимуме управления. Точнее управление контентом есть, и его много, но это ручная работа пиарщиков. или игрушка для секретарши ГД.
2. «присутствие+прямая продажа билетов с оплатой через эквайринг» — требует уже наличие спец. «движка», который общается с инвентором (складом) ресурса мест авиакомпании. Тут часть «движка» занимает от 50% бюджета и работ до 100% проекта, делая его абсолютно невозможным к реализации.
3. «присутствие+ прямая продажа+ продажа через собственные кассы+ субагентская продажа» — пилотаж, где 20% — «присутствие», 30% «движок и ритейл» + 50% система оплаты за проданные перевозки с применением всех механизмов — от ритейла с карточкой до субагентских продаж.
Так вот, это в качестве примера. Если писать план работ, не понимая «кефира», то «присутствие» мы сделаем в любом случае, а все остальное (где и есть бизнес по своей сути) останется одной строкой «а тут аутсорсер делает нам хорошо и мы зарабатываем деньги».
Мое глубокое ИМХО: если сайт включен в бизнес-логику развития компании, то развитие постановочной части (идеи) сайта происходит совместно с развитием бизнеса компании, поэтому можно говорить только о плане стартапа сайта, четко ограничив понимание «кефира». Опять же в качестве примера: жутковато выглядящая «матрица» уважаемого Сергея Лифанова суть перечень абсолютно правильных действий, в правильной последовательности, но я крайне изумлюсь, если увижу некую осязаемую применимость этой методики.
Это как в анекдоте про Щерлока Холмса «где мы, сэр? — вы на воздушном шаре. » К сожалению, в этом моменте кроется причина большинства конфликтов и зря потраченного бюджета на создание сайта компании: одни заказывают, другие создают, третьи -пытаются все это применить и как-то использовать. В авиации эта ситуация доведена до своей критической понятности, по причине специфики бизнеса. Кстати, еще ИМХО: в любой бизнес-структуре создание и использование сайта как части бизнеса есть проектное управление в чистом виде. Чище трудно придумать. Но это ИМХО.
+362 Максим Беспалов Директор по развитию, Москва 22 июля 2009, 11:27
И последняя копейка, просто как ассоциация. мы все смотрим фильмы про «виртуальную реальность», «матрица», где bad guy проводит казни через интернет или отключает мотор у good girl дистанционно. Но, с точки зрения бизнеса — это и есть другая реальность. я бы сказал — другая страна. там живет другой народ, свой язык, сфои формы реагирования, свои предпочтения.
Не психологически — технологически свои. Вот вы же не будете открывать филиал в Зимбабве и поручать руководить развитием бизнеса «по направлениям»? Вы возьмете представителя, который будет осваивать Зимбабве за всю компанию целиком. И если этот представитель не может решить вопрос с любым из менеджеров из головного офиса, он идет к ГД.
ГД берет менеджера за хобот и предлагает ему сделать все «вчера». ведь так? Поэтому, я бы сказал, хочешь успешный интернет-проект как доп. направление развития бизнеса — возьми грамотного РП, поставь на уровень вице-президента и дай ему возможность регулярно входить в свой кабинет за помощью. Тогда проект будет эффективен или малозатратен (все вдруг поняли что ГД это не нужно).
Просто мнение, суммарно по нескольким веткам, которые успел с утра почитать. Это в добавление к методике и плану работ по созданию сайта. Или — коллективное участие + безответственность (игрушку пишем), или — создаем дубликат своей компании в миниатюре (технологически это будет видно) как представительство в другой стране.
Источник: www.e-xecutive.ru
Бизнес-процесс управления разработкой
Эта статья поможет организовать процесс разработки сайтов, приложений и других цифровых продуктов для команд на аутсорсе и инхаус. Здесь описан жизненный цикл задачи от постановки в таск-трекер до релиза в продакшн и дана схема бизнес-процесса.
Текущие описание — результат эволюции подхода к управлению разработкой в моей аутсорс-компании panfilov.digital с 2013 года. Я также помогаю внедрять эту систему в рамках консалтинга. Процесс отлажен на производственных командах до 20 человек, в которых задействованы менеджеры, тимлиды, разработчики, тестировщики, дизайнеры. Скорее всего, он без проблем масштабируется и на большее количество участников.
Я буду рассказывать о процессе разработки, но подход может быть применён на любом «цифровом производстве», где есть менеджеры, исполнители и руководители групп: например, в дизайне, маркетинге, создании контента.
Подход описан на базовом уровне без учёта возможной автоматизации многих процессов, таких как автотесты и DevOps. Статья адресована не только профессионалам в разработке, поэтому для специальных технических терминов будут даны пояснения.
Задачи и роли в команде
Производственный процесс разработки должен решать следующие задачи:
- укладываться в сроки;
- создавать качественный продукт;
- обеспечивать преемственность кода, чтобы было легко масштабироваться;
- приносить больше денег, чем тратить.
Обязательны три роли: менеджер, тимлид и разработчик. Если у вас есть отдельная роль тестировщика, он тоже участвует в процессе.
Менеджер отвечает за сроки и себестоимость проекта. Он собирает материал для работы, формулирует требования, руководит проектом и ставит задачи.
Тимлид отвечает за техническую архитектуру, качество кода и соблюдение сроков разработки. Тимлид контролирует загрузку исполнителей и организует релиз на продакшн.
Разработчик пишет код. Мы считаем, что разработчик выполняет задачу, когда он делает свою работу качественно и в срок, не превышая оценку.
Тестировщик тестирует задачи на предмет функциональных ошибок и составляет баглисты.
— продакшн площадка («прод», «продуктив», «бой», production) — сервер, хостинг, на котором расположена версия сайта или приложения, доступная пользователям;
— релиз (stable release», «деплой», «вылить на прод», deployment) — загрузка кода на продакшн, когда новая версия продукта становится доступна пользователям.
Настройка таск-трекера
Чтобы реализовать предложенную схему управления разработкой, подойдёт любой таск-менеджер, в котором можно устанавливать статусы для задач. Если нужен трекинг времени, то выбирайте сервис с учётом этого, либо попросите исполнителей вносить затраты вручную.
Популярные сервисы для управления задачами: Asana, Trello, Notion, Wrike, Clickup. Сервисы специально под задачи разработки: Jira, Pivotal. В panfilov.digital мы используем YouTrack.
Так выглядит форма добавления задачи в YouTrack
У задачи должна быть следующая структура полей:
- Assignee — исполнитель задачи;
- Due Date — дедлайн;
- Estimation — оценка времени на выполнение задачи;
- Priority — приоритет. Три основных значения: Normal (обычная задача), Major (важно, но не критично), Critical (важно). Есть ещё Show-stopper — когда что-то сломалось настолько, что напрямую вредит бизнесу;
- Spent time — потраченное время, в идеале автоматически заполняется таймером;
- State — статус задачи.
Описание статусов в регламенте по управлению задачами
Три правила работы с таск-трекером:
— если задачи нет в трекере, её не существует;
— если у задачи нет оценки и дедлайна, её можно не делать;
— если время не списано в трекере, оно не потрачено.
Жизненный цикл задачи по разработке
Жизненный цикл задачи от постановки до релиза состоит из четырёх этапов:
- Проектирование и оценка
- Выполнение задачи
- Приёмка
- Релиз
Блок-схема бизнес-процесса управления разработкой
В этом процессе исполнители передают задачу друг другу через смену Assignee и меняют её статус (поле State).
Проектирование и оценка
Роль менеджера. Менеджер ставит задачу: готовит описание и собирает все необходимые данные для начала работы. Затем передаёт задачу тимлиду.
Роль тимлида. Тимлид проверяет задачу на полноту, чтобы менеджер не упустил важных деталей. Если чего-то не хватает, возвращает задачу менеджеру. Когда проверка тимлидом пройдена, задача переходит к разработчику.
Если задача крупная, тимлид декомпозирует её и также может отдать разным исполнителям.
Для каждой задачи нужна предварительная оценка (поле Estimate). Не буду углубляться в методы оценки творческих задач (а программирование — это творческая деятельность), уточню, что оценка нужна для планирования проекта, хотя бы приблизительного.
Есть два подхода к формированию оценки задачи:
- Исполнитель оценивает задачу сам, а тимлид согласовывает. Если тимлид не согласен с оценкой, это сигнал, что требования сформулированы неправильно или у разработчика недостаточно информации.
- Задачу оценивает тимлид, а разработчик принимает или не принимает его оценку.
Общее правило — одна задача не должна быть с оценкой больше 8 часов. Если оценка получается больше, то задачу декомпозируют.
Когда оценка согласована, тимлид устанавливает дедлайн в поле Due date в зависимости от загрузки исполнителя.
Роль разработчика. В процессе анализа задачи исполнитель готовит план реализации — это набросок схемы будущего решения, понимание задачи исполнителем. Часто в процессе подготовки плана исполнитель настолько глубоко погружается в задачу, что на само написание кода уходит меньше времени, чем на проектирование — это нормально, посколько время на подготовку плана тоже учитывается в задаче.
Когда согласована оценка и готов план реализации, исполнитель берёт задачу в работу.
Выполнение задачи
Роль разработчика. Когда начинается работа над задачей, исполнитель меняет статус на In progress — в этот момент включается таймер. Если задача ещё не выполнена, но таймер нужно остановить, устанавливается статус Paused.
Время в задачу могут по очереди списывать несколько исполнителей, для этого необязательно создавать отдельные задачи:
- разработчик — на выполнение задачи и багфикс,
- тимлид — на кодревью,
- QA — на тестирование.
Таким образом видно, сколько всего у команды ушло времени на задачу.
В процессе выполнения могут возникать вопросы, которые препятствуют дальнейшей работе — абсолютно всё невозможно предвидеть на этапе проектирования. Если так случается, задачу переводят в статус To be discussed и переназначают тому, кто может дать ответы.
Ещё бывает, что разработчик в какой-то момент понимает, что не укладывается в первоначальную оценку или дедлайн. В этом случае он сразу же в комментариях просит тимлида согласовать новую оценку и сообщает причину.
Система контроля версий (version control) — система для хранения исходного кода; самая распространённая — git;
репозиторий (repository, «репа») — виртуальный контейнер с кодом: обычно под каждый проект — свой репозиторий, или два: для бекенда и для фронтенда;
ветка (branch) — ответвление от основной версии кода, с копией которого разработчик работает до релиза в продакшн
Когда разработчик заканчивает работу над задачей:
- выливает весь код в репозиторий,
- пишет в комментарии номер ветки,
- устанавливает у задачи статус Fixed,
- переводит её на тимлида.
Приёмка
Перед тем, как подготовить релиз, задача проходит несколько уровней проверки.
Роль тимлида. У тимлида есть список задач в статусе Fixed, которые перевели ему разработчики. На проверку отводятся сутки. Тимлид берёт их в порядке очереди, проводит code review и поверхностно проверяет на соответствие изначальным требованиям.
Code review — процесс проверки кода на предмет ошибок: обычно поводит тимлид, но возможен перекрёстный код ревью, когда разработчики проверяют друг друга.
Тестовый сервер («dev-площадка», «дев») — серверная площадка, на которой развёрнута копия production-сервера. Используется для тестирования перед релизом. Чаще всего закрыта паролем (для веб-проектов — http-авторизация).
Роль менеджера. Если с кодом всё ок, то задача поступает менеджеру в статусе Ready to Check. Здесь менеджер вправе подключить QA (тестировщика), если задача комплексная и её нужно протестировать на разных браузерах и платформах.
Чтобы протестировать задачу, на тестовом сервере включают ветку git с версией кода, в которой она реализована, и проходят по тест-плану. Если всё круто, ставят статус Verified — задача готова к релизу. Если есть ошибки — возвращают исполнителю вместе с баг-листом.
Деплой на боевом сервере
Роль тимлида. Тимлид готовит релиз из задач в статусе Verified и заливает результат на боевой сервер по одной из трёх схем:
- непрерывный деплой — задачи выливаются в ближайший деплой;
- деплой по требованию — задачи выливаются только по указанию менеджера;
- система релизов — несколько задач сливаются в одну ветку, и происходит дополнительный этап тестирования всего релиза.
После деплоя тимлид присваивает задаче статус Deployed.
Роль менеджера. Менеджер проверяет проект на боевом сервере. Если всё хорошо — задача получает заветный статус Completed. Ура, мы справились!
Если на продакшене оказывается неработающий код, то релиз откатывается обратно, но такое случается редко. Задача специально проходит несколько уровней контроля, что практически исключает наличие критических ошибок на проде.
Что нужно для управления разработкой
- Выделить роли менеджера, тимлида и разработчика, определить их зоны ответственности и обязанности.
- Выбрать сервис для управления задачами, настроить поля у сущности задачи и трекинг времени.
- Построить серверную инфраструктуру с площадками для теста и продакшном.
- Контролировать дисциплину выполнения бизнес-процесса.
- Улучшать процесс, если выясняется, что какие-то шаги неэффективны.
Если вы оставите донат, то я пойму, что статья принесла вам ощутимую пользу и продолжу делиться такими материалами.
Источник: panfilov.online
Бизнес-процессы разработки сайта
Общая схема процессов разработки сайта
Сбор требования по проекту, выяснение целей, выработка первоначальных предложений и примерной структуры сайта
Цель
Понять и задокументировать список целей проекта для Заказчика, основные требования к структуре проекта, результаты проекта, ограничения проекта и допущения проекта.
Ответственные исполнители
Менеджер по продажам (вместе с менеджером проекта) — выясняет цель проекта, первичные даные, имеющиеся у Заказчика, требования по проекту, ограничения проекта, результаты проекта. Техлидер проекта (техдиректор) формирует объем работ по проекту.
Контроль
Руководитель отдела внедрения, исполнительный директор.
Входящие данные
Все, что может предоставить заказчик, переговоры с заказчиком, выяснение требований заказчика и целей заказчика.
Написание ТЗ по проекту, разработка структуры сайта, сценариев работы с разделами сайта, требований.
Цель
Выявление всех уточненных требований по работе сайта, структуры разделов сайта, описание возможностей разделов сайта, сченариев поведения на сайте.
Ответственные исполнители
Аналитик проекта
Контроль
Менеджер проекта, заказчик.
Уточненное планирование
Цель
Формирование базовых планов проекта.
Ответственные исполнители
Менеджер проекта.
Исполнители
Техлидер (тех. директор), аналитик проекта, ответственный за дизайн и верстку, тестлидер.
Контроль
Куратор проекта, заказчик.
Входящие данные
Содержание проекта, ТЗ.
Исходящие данные
Заполнение разделов плана управления проектом: управление проектом, Роли и ответственнсти, взаимодействие в ходе проекта, ресурсный план, требования к команде.
Составление: плана управления рисками, структуры работ,[v3] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.
Разработка макета сайта
Цель
Разработка макета сайта, модели работы разделов, формирование всех необходимых элементов управления сайтом, их видов, необходимых рабочих слоев, проработка юзабилити сайта.
Консультанты
Техлидер (тех. директор), аналитик проекта.
Контроль
Менеджер проекта, заказчик.
Входящие данные
Содержание проекта, ТЗ.
Исходящие данные
Модель сайта (макеты страниц) в формате Axure, в HTML.
Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v4] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.
Разработка дизайн-макетов
Цель
Разработка графического исполнения страниц модели сайта.
Консультанты
Техлидер (тех. директор), верстальщик.
Контроль
Менеджер проекта, заказчик.
Входящие данные
ТЗ, модель сайта.
Исходящие данные
Графические макеты в формате Photoshop, Flash, другие необходимые форматы.
Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v5] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.
Верстка макетов
Цель
Перевод графического исполнения страниц модели сайта в язык разметки HTML.
Консультанты
Техлидер (тех. директор), дизайнер.
Контроль
Дизайнер (контроль соответствия), менеджер проекта (сроки).
Входящие данные
Модель сайта, макеты дизайна.
Исходящие данные
Макеты страниц в HTML.
Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v6] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.
Разработка функционала
Цель
Реализация функционала согласно ТЗ и модели сайта.
Консультанты
Аналитик, дизайнер, верстальщик.
Контроль
Техлидер (контроль соответствия), менеджер проекта (сроки).
Входящие данные
ТЗ, макеты дизайна, верстка.
Исходящие данные
Работающий сайт.
Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v7] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.
Разработка документации пользователя
Цель
Предоставление заказчику полного пакета документов по сайту для обучения и работы редакторов и программистов заказчика.
Контроль
Техлидер (контроль соответствия), менеджер проекта (сроки).
Входящие данные
ТЗ, макеты дизайна, верстка, программный код.
Исходящие данные
— ТЗ в котором отражено все, что реализовано
— Описание структуры хранения файлов
— Конфигурационные файлы с комментариями
— Исходный код с комментариями
— Описание процедуры переноса сайта
— Описание развертывания сайта
— Требования к платформе хостинга для полноценного функционирования сайта
Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v8] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.
Тестирование проекта
Цель
Обнаружение ошибок, допущеных при разработке функционала, верстке, внедрении верстки.
Контроль
Тестлидер. В отсутствии – техлидер.
Входящие данные
ТЗ, макеты дизайна, верстка.
Исходящие данные
Список обнаруженных дефектов (багов).
Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v9] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.
Устранение ошибок
Цель
Устранение ошибок, допущеных при разработке функционала, верстке, внедрении верстки.
Консультанты
Аналитик, дизайнер, тестирощик.
Входящие данные
Отчет по багам (список дефектов).
Исходящие данные
Отчет об устранении дефектов.
Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v10] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.
Сдача проекта
Цель
Ввод сайта в эксплуатацию.
Ответственные исполнители
IT-специалист, программисты.
Исходящие данные
Отчет о развертывании сайта и начале полноценной эксплуатации.
Дополнительно
Документальное закрытие проекта менеджером проектов. Получение отчета о закрытии от техлидера, составление аналитических записок о перерасходе/недорасходе бюджета, соответствии плану по времени, проведение совещания по возникщим проблемам на проекте и их причинам. Предложения по ликвидации таких проблем в дальнейшем.
Источник: web-project.livejournal.com