Перед началом проекта: 8 секретов стартовой встречи
Правила успешного kick-off митинга.
Если вам интересна эта тема, то вам точно понравится наша шпаргалка: «Какие шаблоны поведения команды мешают проекту»
Kick-off митинг — это стартовая встреча перед началом проекта. Такие собрания помогают познакомить участников команды, обозначить цели и сделать сотрудничество прозрачным. Конечно, при условии, что встреча проведена правильно.
Перевели советы французского портала Manager GO о том, как организовать kick-off митинг.
Для чего нужна стартовая встреча
Как и любую другую встречу, kick-off митинг нужно тщательно продумать и спланировать. Составьте план встречи и разошлите приглашенным, чтобы они подготовили вопросы и предложения.
Простота и эффективность — вот ключевые характеристики такого собрания. Его цель состоит не в том, чтобы вывалить на участников поток информации, цифр и данных по проекту. А наоборот — облегчить понимание рабочих процессов.
#1. Знакомство
Представьтесь и попросите участников сделать то же. Это особенно важно, когда специалисты незнакомы. Что сказать? Базовую информацию: имя, фамилия, функция в компании. Роль каждого в проекте уточнят позже.
# 2. Повестка встречи
Иногда этим шагом пренебрегают, считая его лишней церемонией. На самом деле, всем будет проще, если вы с самого начала определите, в каком порядке будете обсуждать проект, когда задавать вопросы и т. д. Встречи такого типа — это не монолог. Нужно, чтобы участвовала вся команда.
# 3. Суть проекта и цели команды
Обязательно ответьте на вопрос: «Какие проблемы решает проект?» Сотрудникам важно понимать, почему они будут делать ту или иную работу.
Ольга Киселева,
Проджект-менеджер в MegaFon
Евгений Камашев,
Ex-директор по проектам Метинвест Диджитал
Не забывайте, что на встрече собрались специалисты из разных областей. Укажите общие цели и, если это возможно, уточните их по областям для каждой группы сотрудников. Опишите, какого результата ждете.
# 4. Описание этапов проекта
Разбейте проект на этапы, уточняя результат каждого (макет, документация) и срок выполнения. Так вы убедитесь, что ничего не упустили. Некоторые процессы могут выполняться параллельно. Так вы избежите ситуации, когда сотрудник ждал окончания предыдущего процесса и не приступал к работе, потеряв много времени.
Если для управления проектами вы используете специальную программу (Trello, Redmine, Jira), предупредите об этом в начале.
# 5. Роль и ответственность каждого
Одна из главных целей стартовой встречи — подробно объяснить, кто чем занимается, в какие группы объединяются сотрудники и как работают друг с другом. Например, два дизайнера и один менеджер, который затем отправляет макет на утверждение аналитику и руководителю проекта.
Обязательно составьте список с контактами каждого участника. У точните, как будете коммуницировать. Часто руководители проекта не возражают против коммуникации в Facebook через личные аккаунты. Некоторым важно иметь постоянный доступ к переписке.
# 6. Мониторинг проекта
Авторы Manager GO советуют проводить регулярное информирование о ходе проекта раз в неделю и всегда в письменной форме.
Такой отчет может содержать такие элементы:
Не делайте отчеты бюрократизированными. Выберите только принципиальную для проекта информацию.
# 7. Оценка результатов работы
На стартовой встрече определите, как вы будете оценивать, выполнена ли работа, и насколько хорошо. Сотрудники должны уложиться в сроки? В бюджет? Максимально быстро все согласовать внутри команды? Использовать новые методы или технологии? Совершить наименьшее количество ошибок?
# 8. Планирование следующих встреч
Согласование графика следующих встреч еще раз напомнит сотрудникам о дедлайнах и объеме работы, который они должны сдать в срок.
Евгений Камашев, директор по проектам Метинвест Диджитал
На стартовой встрече также обсудите:
Технологии позволяют собрать всех участников команды, даже если они в разных странах. Чем больше сотрудников будут понимать цели и задачи проекта, тем выше будет их эффективность.
Если не получается собрать всех, пригласите ключевых специалистов — тех, кто будет возглавлять проектные группы. От каждой функции (маркетинг, IТ, финансы) должен быть минимум один представитель.
Можно провести несколько стартовых встреч: внутреннюю и совместно с Заказчиком. Оптимально встреча должна длиться час. Если дольше — теряется фокус внимания.
kick-off meeting
Смотреть что такое «kick-off meeting» в других словарях:
Kick-Off-Meeting — Kick off oder Kickoff steht für: den Anstoß in Ballsportarten wie dem American Football oder Rugby. eine Auftaktveranstaltung zu Beginn eines Projekts in der Wirtschaft (auch „Kick off Meeting“) den Start der Entwicklungsphase in einem… … Deutsch Wikipedia
kick-off meeting — noun The first official meeting of a group of people who will be working together on a project. The agenda will usually include introductions, statement(s) of mission, and organization of teams or working groups. The implication is that there… … Wiktionary
Kick-off-Meeting — Kịck ọff Mee|ting, Kịck|ọff|mee|ting, das (Jargon): Zusammenkunft aller Beteiligten zu Beginn der Arbeit an einem Projekt … Universal-Lexikon
kick-off meeting — Riunione che avviene durante le prime fasi dell iter di quotazione, in cui viene presentato il progetto e vengono definite le responsabilità dei singoli soggetti coinvolti nel processo di quotazione. La preliminary timetable definisce i tempi e … Glossario di economia e finanza
Kick-off-Meeting — D✓Kịck ọff Mee|ting, Kịck|ọff|mee|ting [. mi. ] … Die deutsche Rechtschreibung
Kick-Off — oder Kickoff steht für: den Anstoß in Ballsportarten wie dem American Football oder Rugby. eine Auftaktveranstaltung zu Beginn eines Projekts in der Wirtschaft (auch „Kick off Meeting“) den Start der Entwicklungsphase in einem Softwareprojekt ein … Deutsch Wikipedia
Kick Off — oder Kickoff steht für: den Anstoß in Ballsportarten wie dem American Football oder Rugby. eine Auftaktveranstaltung zu Beginn eines Projekts in der Wirtschaft (auch „Kick off Meeting“) den Start der Entwicklungsphase in einem Softwareprojekt ein … Deutsch Wikipedia
Kick off — oder Kickoff steht für: den Anstoß in Ballsportarten wie dem American Football oder Rugby. eine Auftaktveranstaltung zu Beginn eines Projekts in der Wirtschaft (auch „Kick off Meeting“) den Start der Entwicklungsphase in einem Softwareprojekt ein … Deutsch Wikipedia
Kick-off — oder Kickoff steht für: den Anstoß in Ballsportarten wie dem American Football (Kickoff (American Football)) oder Rugby eine Auftaktveranstaltung zu Beginn eines Projektes in der Wirtschaft (auch „Kick[ ]off Meeting“ genannt) den Start der… … Deutsch Wikipedia
kick|off — «KIHK F, OF», noun, adjective. –n. 1. a kick that puts a football in play at the beginning of each half and after a score has been made. It is made from the defending team s 40 yard line. 2. Informal, Figurative. any move made to begin: »At… … Useful english dictionary
kick off something — ˌkick ˈoff sth derived to start a discussion, a meeting, an event, etc. Syn: ↑open Main entry: ↑kickderived … Useful english dictionary
Правила хорошего kick-off, или как не превратить установочную встречу в балаган
У вас новый проект, много энтузиазма и есть понимание, что эта автоматизация сделает жизнь Заказчика лучше, а вашу зарплату больше? Бизнес-кейс очевиден, что делать – понятно, провал невозможен? А потом вы собираетесь с рабочей группой на kick – off (он же – установочная встреча в российской терминологии) – и энтузиазм внезапно гаснет, вопросов становится больше чем ответов, а отношения с рабочей группой как-то сразу не складываются. И вот у вас идет очередной унылый проект. Знакомо? А ведь можно было избежать, если знать несколько простых правил.
Правило 0. Помните о том, зачем все это нужно
Для начала напомню, что цели проведения kick – off – это а) достижение единого понимание цели проекта б) управление ожиданиями в) знакомство с рабочей группой.
Если держать эти цели в голове при планировании встречи, то будет проще понять, что в нее должно входить, а что нет. От того, как вы проведете kick-off часто зависит дальнейший ход проекта, а в особо запущенных случаях – даже его успех или провал.
Правило 1. Организуйте kick – off только тогда, когда готов
Проводить kick – off имеет смысл только тогда, когда выполнены следующие предварительные условия:
Правило 2. Хороший kick – off – спланированный kick – off
И это сейчас не про то, что встреча должна быть выслана заранее, с приложенным уставом и повесткой, это и так все знают, хотя и не всегда соблюдают.
Необходимо продумать структуру и содержание встречи, в идеале – согласовать все это дело со спонсором. Долгие паузы, фразы «эээ… а зачем мы здесь» и прочие последствия вашей неподготовленности могут сильно испортить как репутацию проекта, так и вашу лично в глазах рабочей группы, с первой же встречи, а оно вам надо?
Правило 3. Лучше не начинать встречу слишком формально
Всех этих людей сюда зачем-то позвали, оторвав от работы, они вас не знают, вы их тоже. Если вы с порога им начнете рассказывать план проекта, то вас могут просто не воспринять.
Поэтому до формального начала встречи используйте «ледокол» – шутку, короткую историю, вопрос о компании – все, что угодно, чтобы перед встречей все не сидели со слишком серьезным видом или смотрели в телефон. Отлично, если вы руководитель проекта и так ненавязчиво смогли обратить на себя внимание и даже немного кому-то понравиться, хотя бы на уровне «о, забавный парень».
Правило 4. Дайте слово спонсору
Дальше слово лучше взять спонсору. Если вы с ним заранее об этом не договорились – то можно аккуратно попробовать передать ему ведущую роль, мол, сейчас Ефимий Евстигнеевич наконец скажет нам, зачем мы все собрались и как это повлияет на наши годовые бонусы. Но это, конечно, зависит от личности конкретного Ефимия Евстигнеевича.
Часть спонсора в идеале выглядит так:
Правило 5. Краткость и профессионализм!
Дальше спонсор может передать слово руководителю проекта, который:
Правило 6. Это нужно помнить, чтобы kick – off прошел успешно
Это как правила безопасности дорожного движения, написано кровью РМов:
Как не набить шишек на старте проекта
Меня зовут Настя, я Unit Manager международной команды в компании Itransition и тренер по управлению проектами в IT-Academy. За почти 10 лет опыта в менеджменте мне довелось поработать с разными заказчиками, продуктами, командами. На старте карьеры меня удивляло, что, согласно статистике PMI, из года в год более половины проектов заканчиваются крахом.
Сейчас я охотно верю этим данным, ведь сколько IT-проектов я ни стартовала, не было ни одного, чтобы все шло идеально. Я также не знаю ни одного практикующего менеджера, у которого бы всегда все шло как по маслу (те, с кем я познакомилась на собеседованиях, не считаются). Как ни печально, многих трудностей можно было бы достаточно легко избежать, или, как минимум, облегчить ход развития событий, предприняв определенные шаги на самом старте проекта.
В данной статье речь пойдет о тех практиках и артефактах, на которые я обращаю особое внимание на старте проекта. Информация будет полезна не только начинающим, но и менеджерам с опытом работы на IT-проектах: для опытных менеджеров примеры будут более понятными, а новички, надеюсь, смогут избежать подобных сложностей в начале карьеры.
Я расскажу как об известных и достаточно банальных, но очень полезных вещах, так и том, чего не встретишь как минимум в первых пяти статьях google на тему «как стартовать проект».
О чем мало говорят, но было бы полезно использовать
Team Charter или манифест команды
Было ли у вас когда-нибудь ощущение, что вы работаете в коллективе, но не команде? У меня было много раз, к сожалению. Первым шагом на пути создания команды я чаще всего выбираю Team Charter. Мне очень нравится этот инструмент, так как он решает сразу несколько задач. При этом важен не только процесс создания манифеста/устава команды, но и получившийся артефакт.
Во-первых, Team Charter позволяет выровнять контекст и узнать о ролях в команде и целях проекта. С командой редко разговаривают о таких вещах, хотя усилий это требует совсем небольших, а эффект от искренней вовлеченности в работу и отсутствия лишних коммуникаций и ложных ожиданий может превзойти все ожидания.
Во-вторых, манифест устанавливает понятные и прозрачные правила игры, что снижает общий уровень тревожности. Старт нового проекта, как и любое изменение, – всегда стресс для всех вовлеченных ввиду большого количества неопределенности. Да, тревожно не только менеджеру. Мы не знаем, как нас примут в новом коллективе, какое поведение здесь поощряется и каким ценностям следуют.
Неопределенность создает психологическое напряжение и страх ошибки, за которым стоит страх непринятия. Это очень глубокая тема, но не хотелось бы уходить в сторону от старта проектов. Поэтому всем заинтересовавшимся рекомендую почитать труды или посмотреть видео Эми Эдмондсон, одного из ведущих исследователей психологической безопасности на рабочем месте.
В-третьих, манифест сокращает время на адаптацию новичков. Так или иначе, мы не застрахованы от смены членов команды. В таком случае манифест даст новичку информацию о том, в какую группу людей он попал, зачем и по каким правилам эта группа существует.
Onboarding Guide или руководство для новичков
Продолжая тему смены членов команды, весьма полезным будет начать создавать руководство по онбордингу для новичков с самого старта проекта. Первое время оно будет служить описанием рутинных процессов (описание проекта, отпуска, больничные, трекинг времени, тимбилдинги, манифест и т.д.) для всех членов команды.
А затем, когда команда привыкнет к этим правилам, гайд станет надежной опорой для каждого новичка. В противном случае вам придется всю эту информацию пересказывать из уст в уста, тратить на этот процесс много времени и встречать досадные неприятности из-за того, что какая-то информация все же потерялась.
Communication plan или план коммуникации
На просторах глобальной сети можно найти великое множество разнообразных шаблонов плана коммуникаций, поэтому будет небольшим лукавством сказать, что о нем мало говорят. Но говорят обычно не предметно, а скорее слишком теоретически. Я считаю этот инструмент крайне полезным, поэтому поделюсь, как я его использую в своей практике.
Обычно создаю на Confluence страницу под названием Communication plan, где располагается таблица. Ее верхняя строка представляет собой таймлайн – схему рабочей недели или месяца (зависит от продолжительности итераций, по которым выстраиваются рабочие процессы). Следующие строки посвящены инструментам коммуникации, обычно это встречи и разного рода отчеты.
Остается только отметить на таймлайне, какие из этих инструментов будут использованы и когда. Это позволяет увидеть, насколько равномерно распределены встречи, нет ли нагромождений из митингов и перерасхода времени на коммуникацию. Таблицу можно дополнять различными деталями и ссылками, а также обязательными и необязательными участниками. То же самое можно сделать в отдельном календаре Outlook, не всем удобно размещать напоминания об отчетах в этом инструменте в качестве события.
Реестр юридических документов
Здесь все просто: чтобы ничего важного не потерять и не забыть, лучше сразу все хранить в одном месте, будь то папка на Sharepoint или страничка на Confluence. Важно помечать «срок годности», чтобы вовремя обновлять необходимые документы.
Это позволит избежать ситуации, когда команда отработала очередной месяц, клиент внезапно перестал платить по счетам, а документы по оказанию услуг уже просрочены и подписывать снова их никто не собирается – средства закончились.
О чем многие знают, но часто забывают
Договор
Что является отправной точкой для старта проекта? В сервисных IT-компаниях, как правило, – подписание контракта. Но почему-то этот самый контракт менеджеры не считают нужным прочитать. Постараюсь кратко описать, что полезного там можно найти, помимо всем известных сроков и стоимости поставки:
Deliverables или объем поставляемых услуг
Сюда, бывает, не заглядывают до самого окончания проекта – и потом находят много интересного. В объем поставки, помимо кода, может входить различная документация и дополнительные услуги. Зная о таких нюансах, можно все эти артефакты подготовить заранее, в спокойном режиме.
К примеру, на одном из проектов в комплект поставки должны были входить требования в виде спецификации. Но, не обратив на это внимание, команда работала над требованиями только в виде описания Jira-тикетов. Благо, все закончилось мирно и заказчику этого оказалось достаточно, но для этого менеджеру на пару с бизнес-аналитиком пришлось приложить немало усилий.
Assumptions или допущения
Допущения, обычно, формируются на этапе оценки проекта, но не всегда оправдываются, хоть и влияют на оценку проекта. С другой стороны, зачастую assumptions – это оплот надежды менеджера не остаться крайним, когда все идет наперекосяк по каким-то внешним причинам. Допущения позволяют вести переговоры с заказчиком не с позиции оправдывающегося, а на равных. С другой стороны, допущения тесно связаны с рисками и дают нам фору в борьбе с обстоятельствами.
Например, в допущениях указано, что заказчик предоставит готовые API для разработки front-end. Соответственно, есть риск того, что это допущение окажется ошибочным. В таком случае команде придется, как минимум, приложить дополнительные усилия на интеграцию с серверной частью приложения. Задача менеджера – определить, насколько сильным будет влияние на проект риска, что допущение окажется ошибочным, и составить план «Б».
Процедура приемки
Даже когда проект идет прекрасно, команда счастлива, а заказчик вас боготворит, все может измениться на этапе приемки. Поверьте, когда вы распустите команду, ваш бэклог будет полон минорных багов, а заказчик откажется принимать проект, пока все не пофиксят, вы вспомните об этом пункте договора. Если в договоре явным образом не указывается уровень качества поставляемого программного обеспечения, обязательно внесите пункт «согласовать стратегию тестирования с заказчиком» в свой чек-лист по старту проекта.
В этом же пункте обычно описываются отчеты, которые исполнитель обязан предоставлять заказчику, а также порядок приемки этих отчетов. В данном случае не рекомендую действовать исключительно «по букве закона» и спать спокойно, если заказчик не ответил на ваше письмо с проблемным отчетом в течение оговоренного срока. Обычно это означает, что существует риск «нарваться» на еще большие проблемы и непонимание заказчика в будущем, хотя, согласно договору, отчет и считается принятым.
Я указала только три пункта, но договор нужно и важно читать полностью, вдумчиво! На моей практике были примеры, когда менеджер обещал клиенту гарантию, руководствуясь своим опытом работы с контрактами в другой компании, хотя в текущем контракте она не была прописана. Бывало, что осуществляли замену членов команды, не соблюдая условия договора, что влекло за собой праведный гнев заказчика. А ведь можно было этого легко избежать.
Устав проекта
Я очень часто слышала, что устав – это атавизм, он никому не нужен и ценности никакой не несет. Но договор доступен далеко не всей команде, а альтернативного артефакта, где указана вся основная информация о проекте, пока не придумали. Устав проекта совершенно не обязательно должен быть официальным документом – достаточно аккуратной странички на Confluence или Wiki со всеми необходимыми ссылками.
Даже если вы работаете по типу контракта dedicated team, устав заставит вас задуматься, чего же на самом деле хотят ваши стейкхолдеры. Такие мысли, подкрепленные конкретными действиями, переводят вас из разряда администраторов в управленцев. На мой взгляд, устав, как предмет гигиены, как заглавие книги, должен быть у любого проекта.
Kick-off Meeting или встреча по инициации проекта
Я бы сравнила kick-off с первым свиданием: от того, как пройдет первое, во многом зависит, будет ли продолжение. Да, отношения с заказчиком подкреплены договором, но никто не застрахован от эскалации и просьбы сменить менеджера. Только вот почему-то далеко не всегда к kick-off готовятся так же трепетно, как к первому свиданию. Я не буду говорить про повестку встречи, но вот на что я рекомендую обратить внимание:
Подготовьтесь и проведите внутренний kick-off. Это позволит вам отрепетировать звонок с заказчиком, пообщаться с командой, с pre-sales, собрать всю возможную информацию и создать список открытых вопросов. Как результат, вы будете более подготовленными и менее тревожными.
Подготовьте презентацию. Она сильно облегчит вам задачу как докладчику и позволит всем участникам встречи легче улавливать информацию, быть всегда в одном контексте. Инструментов для этого достаточно: Microsoft PowerPoint, Miro, Prezi – выбор на любой вкус.
Убедитесь, что у всех участников с вашей стороны включены камеры, налажен звук микрофона, всех хорошо видно, у всех надлежащий внешний вид. Созвонитесь за 30 минут до звонка с клиентом, чтобы все проверить. Все уже привыкли к условиям удаленки, поэтому если вдруг на заднем плане у кого-то появится кот или ребенок – это не страшно. Страшно, если вы начнете вести себя неадекватно и кричать на ребенка или кота.
Предупредите клиента о формате звонка. Обычно я высылаю презентацию заранее, чтобы он смог подготовиться, а также внести дополнения или правки при необходимости.
Вышлите follow-up и приглашения на последующие встречи. Если вы не задокументируете ваши договоренности – будьте уверены: о них забудут или, что хуже, в момент наступления проблем будут использовать не в вашу пользу.
Я видела проекты, на которых не было ни внутреннего, ни внешнего kick-off. Также видела проекты, где kick-off проходил без презентаций и качественной подготовки. Они не закрывались, но, помимо налета безразличия со стороны менеджмента, появлялись другие, более серьезные проблемы.
Например, не было выявлено, что клиент не знаком с методологией Scrum и просто не понимает роль владельца продукта, которой его «наградил» менеджер. Или выявлялись критические расхождения в понимании уровня прозрачности процессов разработки, в результате чего появлялись эскалации.
Заключение
Пока писала статью, несколько раз ловила себя за руку, чтобы не углубиться в какую-то из вышеупомянутых тем. Хоть это далеко не все, что входит в работу менеджера в начале проекта. Надеюсь, список получился полезным и поможет вам избежать некоторых трудностей с самого старта. Все эти инструменты не панацея, главное – понимать, в чем их польза и зачем менеджеру их использовать. Если вам есть чем поделиться по этой теме, буду рада обсудить в комментариях!
Предотвращение ошибок: Desk Check и стартовая встреча
При работе над пользовательскими историями (user story) очень легко допустить оплошность. Если не выявить ошибку до начала разработки, желаемого результата можно не получить вовсе. В голове аналитика детали проекта просты и понятны, но на практике не всегда могут быть адекватно выражены в виде user story.
Сегодня мы поговорим о том, как можно предупредить появление ошибок еще до начала или на ранних этапах разработки приложений. Для этого существуют и применяются разнообразные приемы, которые помогают выявить потенциальный недостаток до того, как он проявит себя.
Многие из таких приемов описаны в новой книге Гойко Аджича (Gojko Adzic) «Fifty Quick Ideas To Improve Your Tests». Наиболее эффективными, с нашей точки зрения, оказались два подхода: проведение стартовой встречи (Kick-off meeting) и Desk Check (анализ историй «за столом»).
Анализируемые истории лишний раз лучше пересмотреть, поэтому хорошей идеей будет встреча команды, где аналитик (или другой член команды, имеющий представление о проекте) представит намеченные истории, опишет их ценность, происхождение и расскажет, зачем они нужны.
Это даст команде возможность обсудить технические аспекты и задать вопросы, чтобы прояснить некоторые требования и оценить размеры истории. Все замечания и комментарии, полученные в ходе собрания, могут быть учтены, чтобы разбить историю на несколько частей или, наоборот, добавить к ней больше деталей и примеров, то есть прояснить места, вызвавшие затруднения.
Стартовая встреча
На данном этапе рассматривается список вопросов (состоящий из нескольких пунктов), на которые нужно обязательно ответить перед тем, как начинать разработку. Вопросы могут быть следующего характера: завершен ли анализ историй, и можно ли начинать разработку? каким техническим решениям стоит уделить особое внимание во время разработки? достаточно ли информации о визуальном оформлении? как поступить с сообщениями об ошибках и подсказками?
Часто возникает такая проблема, когда разработчик не делится своими идеями и не согласует их с аналитиком (возникает недопонимание).
Именно поэтому проводится предстартовая встреча, чтобы команда пообщалась и поделилась своими мыслями. Это позволяет учесть все тонкости и важные детали; каждый член команды играет свою роль и имеет собственные соображения касательно историй.
В идеале, на стартовой встрече необходимо присутствие бизнес-аналитика, QA-инженера и разработчиков, тогда все они познакомятся с разрабатываемым функционалом приложения. Это сделает обсуждение более продуктивным и полезным.
Вот пример нашего списка вопросов, обсуждаемых на стартовой встрече:
Desk Check
Этот вид анализа проводится только тогда, когда группа разработчиков уверена, что разработка окончена. В списке ниже представлены следующие вопросы: было ли проведено приемочное тестирование? было ли проведено модульное тестирование? приглашали ли вы кого-нибудь проверить ваш код? тестировался ли продукт во всех (популярных) браузерах?
Эти вещи важны, и они помогают избежать проблем в будущем. Например, тот или иной функционал приложения будет отлично работать в Chrome, но отображаться в Internet Explorer с ошибками, потому что последний не поддерживает используемые вами библиотеки.
Участники: бизнес-аналитик, разработчики, заказчики (interested parties).
Обратите внимание, что выше представлены лишь примеры вопросов, и вам не стоит принимать их в качестве эталона. Выгода этого подхода заключается в том, что можно проверить, все ли важные шаги были учтены в процессе разработки.
Еще одна вещь, о которой стоит помнить – все эти списки должны быть персонализированы, поскольку каждый проект обладает своими особенностями и целями. Попробуйте создать свои собственные и посмотрите, какой эффект они окажут на качество разработки. Превратите это в привычку, и она перерастет в навык.
16 сентября 2015 (в среду) в 18:30 в Акселераторе ФРИИ состоится воркшоп с ex-руководителем мобильных и десктоп продуктов LinguaLeo, основателем AppCraft и гуру метрик — Ильей Красинским.
Тема: «Продуктовая аналитика: как сделать верные выводы и сфокусироваться на точках кратного роста». Регистрация бесплатна.
