Ретроспектива проекта (еще её иногда называют «postmortem») — это ритуал, который совершается в конце проекта и помогает посмотреть на проделанную на проекте работу и сделать из неё какие-то выводы. Ретроспектива помогает сделать две вещи:
1. Посмотреть, что мы по итогам проекта получилось хорошо. И разобраться, почему оно получилось хорошо: это нам просто повезло или мы целенаправленно и систематически делали в течение проекта что-то полезное, что дало нам нужный результат?
2. Посмотреть, что мы по итогам проекта получилось плохо. И, разумеется, разобраться в причинах обнаруженных проблем и сделать соответствующие выводы.
По итогам ретроспективы все члены команды делают (ну или должны делать) определенные выводы, которые позволят сделать следующий проект лучше, что бы это «лучше» в каждом конкретном случае ни значило.
Как устроена наша, джугрушная, ретроспектива:
Ретроспектива проводится после каждой конференции. Если конференции идут одна за другой — их ретроспективы можно объединять. На первом этапе список обнаруженных проблем и достижений собирается в единую табличку во внутренней вики (у нас Confluence). У списка есть несколько источников:
1. Собственные наблюдения членов команды. В нашем случае это самый богатый по количеству пунктов источник
2. Фидбэк от участников. 70-80% наших участников оставляют нам после конференции свои отзывы. На каждой конференции их несколько сотен
3. Фидбэк от спикеров — обычно это пара десятков отзывов.
4. Фидбэк от спонсоров — обычно это несколько (5-10) отзывов
5. Фидбэк от информационных партнеров
Для пунктов 2, 3 и 4 мы используем онлайн-сервис SurveyMonkey. Раньше использовали более простой Google Forms, но давно его переросли. Ещё народ использует Typeform, но нам он пока не нравится — SurveMonkey помощнее будет. Собственные наблюдения каждый член команды записывает сам на бумажку или Evernote или что-то такое, потом ручками переносит в табличку. Фидбэк от инфопартнёров собирается сотрудником отдела маркетинга банально по e-mail.
В получившейся табличке у нас несколько колонок:
1. обнаруженная проблема/достижение. Сформулировано оно в виде некоторого факта. Например, «на мобильных версиях наших конференционных сайтов часто обнаруживаются баги» или «на обеде конференции DotNext наконец-то не было очередей».
2. Конференция, на которой эта проблема (или достижение) была обнаружена. Если проблема носит системный характер — пишем не название конференции, а «All».
3. проблема это, успех это или непонятно. Обозначается у нас значками плюса, минуса или знаком вопроса соответственно
4. Зона ответственности: с какой частью мероприятия связан данный пункт: Доклады, Сайты, Площадка, Реклама и т.д.
5. Автор данного пункта. Сюда каждый боец заносит либо себя любимого.
6. Решение проблемы. Перед ретроспективой это поле не заполняется.
7. Тикет (задачка) в JIRA. Перед ретроспективой это поле тоже не заполняется.
На заполнение таблички мы даём две недели. После чего мы переходим ко второму этапу: табличка разрезается на несколько кусков (обычно снова по сферам ответственности: маркетинг, оборудование, площадка, кейтеринг, доклады) и каждая команда, отвечающая за соответствующий кусок конференции, проводит совещание, разбирая все обнаруженные пункты и заполняя поле «решение». Типичная продолжительность ретроспективы в каждом из наших отделов — от одного до четырёх часов.
Далее, часть принятых во время ретроспективы решений подразумевают за собой какие-то действия со стороны членов команды. После ретроспективы её ведущий создаёт соответствующие тикеты в JIRA и проставляет номера этих тикетов в последнюю колонку таблички. К каждому из созданных после ретроспективы тикетов добавляется label «ретроспектива» Всё, ретроспектива закончена: проблемы проговорены, выводы сделаны, тикеты заведены.
В итоге около 80% обнаруженных проблем нам удаётся решить внутри отдела, не отвлекая коллег из соседних отделов. Вообще полезно через пару месяцев после прошедшей ретроспективы провести её третий этап: вновь собраться по отделам и посмотреть на результаты. То есть, пройтись по тикетам с пометкой «ретроспектива» и посмотреть, какие их решены, какие ещё нет, а какие вообще не двигаются. Мы этот третий этап делаем, к своему стыду, довольно редко и спонтанно. Надо бы внимательнее относиться к этому вопросу.
Но что делать в случае, когда в проблему вовлечено несколько команд сразу? Например, когда от разных команд поступают разные требования или у нескольких команд есть разные мнения по тому или иному поводу? Что делать, когда команда не может самостоятельно выработать решение по тому или иному вопросу? Тогда нужно проводить высокоуровневую ретроспективу. О ней — в следующем посте.
----
Полезняшки:
1. Сервис онлайн-анкет SurveyMonkey, который мы используем для сбора обратной связи: https://www.surveymonkey.com/
2. Книга: Норм Керт. Ретроспектива проекта. Как проектным командам оглядываться назад, чтобы двигаться вперед — под редакцией [id235585242|Максима Дорофеева] . https://www.ozon.ru/context/detail/id/31497960/
3. Цикл постов [id969857|Никиты Макарова] о том, как он делает ретроспективы в свой команде: http://bit.ly/makarov-retro
----
А вы проводите у себя ретроспективы? Что на них получается, а что нет?
1. Посмотреть, что мы по итогам проекта получилось хорошо. И разобраться, почему оно получилось хорошо: это нам просто повезло или мы целенаправленно и систематически делали в течение проекта что-то полезное, что дало нам нужный результат?
2. Посмотреть, что мы по итогам проекта получилось плохо. И, разумеется, разобраться в причинах обнаруженных проблем и сделать соответствующие выводы.
По итогам ретроспективы все члены команды делают (ну или должны делать) определенные выводы, которые позволят сделать следующий проект лучше, что бы это «лучше» в каждом конкретном случае ни значило.
Как устроена наша, джугрушная, ретроспектива:
Ретроспектива проводится после каждой конференции. Если конференции идут одна за другой — их ретроспективы можно объединять. На первом этапе список обнаруженных проблем и достижений собирается в единую табличку во внутренней вики (у нас Confluence). У списка есть несколько источников:
1. Собственные наблюдения членов команды. В нашем случае это самый богатый по количеству пунктов источник
2. Фидбэк от участников. 70-80% наших участников оставляют нам после конференции свои отзывы. На каждой конференции их несколько сотен
3. Фидбэк от спикеров — обычно это пара десятков отзывов.
4. Фидбэк от спонсоров — обычно это несколько (5-10) отзывов
5. Фидбэк от информационных партнеров
Для пунктов 2, 3 и 4 мы используем онлайн-сервис SurveyMonkey. Раньше использовали более простой Google Forms, но давно его переросли. Ещё народ использует Typeform, но нам он пока не нравится — SurveMonkey помощнее будет. Собственные наблюдения каждый член команды записывает сам на бумажку или Evernote или что-то такое, потом ручками переносит в табличку. Фидбэк от инфопартнёров собирается сотрудником отдела маркетинга банально по e-mail.
В получившейся табличке у нас несколько колонок:
1. обнаруженная проблема/достижение. Сформулировано оно в виде некоторого факта. Например, «на мобильных версиях наших конференционных сайтов часто обнаруживаются баги» или «на обеде конференции DotNext наконец-то не было очередей».
2. Конференция, на которой эта проблема (или достижение) была обнаружена. Если проблема носит системный характер — пишем не название конференции, а «All».
3. проблема это, успех это или непонятно. Обозначается у нас значками плюса, минуса или знаком вопроса соответственно
4. Зона ответственности: с какой частью мероприятия связан данный пункт: Доклады, Сайты, Площадка, Реклама и т.д.
5. Автор данного пункта. Сюда каждый боец заносит либо себя любимого.
6. Решение проблемы. Перед ретроспективой это поле не заполняется.
7. Тикет (задачка) в JIRA. Перед ретроспективой это поле тоже не заполняется.
На заполнение таблички мы даём две недели. После чего мы переходим ко второму этапу: табличка разрезается на несколько кусков (обычно снова по сферам ответственности: маркетинг, оборудование, площадка, кейтеринг, доклады) и каждая команда, отвечающая за соответствующий кусок конференции, проводит совещание, разбирая все обнаруженные пункты и заполняя поле «решение». Типичная продолжительность ретроспективы в каждом из наших отделов — от одного до четырёх часов.
Далее, часть принятых во время ретроспективы решений подразумевают за собой какие-то действия со стороны членов команды. После ретроспективы её ведущий создаёт соответствующие тикеты в JIRA и проставляет номера этих тикетов в последнюю колонку таблички. К каждому из созданных после ретроспективы тикетов добавляется label «ретроспектива» Всё, ретроспектива закончена: проблемы проговорены, выводы сделаны, тикеты заведены.
В итоге около 80% обнаруженных проблем нам удаётся решить внутри отдела, не отвлекая коллег из соседних отделов. Вообще полезно через пару месяцев после прошедшей ретроспективы провести её третий этап: вновь собраться по отделам и посмотреть на результаты. То есть, пройтись по тикетам с пометкой «ретроспектива» и посмотреть, какие их решены, какие ещё нет, а какие вообще не двигаются. Мы этот третий этап делаем, к своему стыду, довольно редко и спонтанно. Надо бы внимательнее относиться к этому вопросу.
Но что делать в случае, когда в проблему вовлечено несколько команд сразу? Например, когда от разных команд поступают разные требования или у нескольких команд есть разные мнения по тому или иному поводу? Что делать, когда команда не может самостоятельно выработать решение по тому или иному вопросу? Тогда нужно проводить высокоуровневую ретроспективу. О ней — в следующем посте.
----
Полезняшки:
1. Сервис онлайн-анкет SurveyMonkey, который мы используем для сбора обратной связи: https://www.surveymonkey.com/
2. Книга: Норм Керт. Ретроспектива проекта. Как проектным командам оглядываться назад, чтобы двигаться вперед — под редакцией [id235585242|Максима Дорофеева] . https://www.ozon.ru/context/detail/id/31497960/
3. Цикл постов [id969857|Никиты Макарова] о том, как он делает ретроспективы в свой команде: http://bit.ly/makarov-retro
----
А вы проводите у себя ретроспективы? Что на них получается, а что нет?
The retrospective of the project (sometimes called “postmortem”) is a ritual that is performed at the end of the project and helps to look at the work done on the project and draw some conclusions from it. Retrospective helps to do two things:
1. See that we are good at the end of the project. And to understand why it turned out well: did we just get lucky or did we purposefully and systematically do something useful during the project that gave us the desired result?
2. To see what we are following as a result of the project is bad. And, of course, understand the causes of the problems found and draw the appropriate conclusions.
According to the results of the retrospective, all team members draw (well, or should do) certain conclusions that will make the next project better, whatever that means, “better” in each case.
How our jugrushnaya retrospective is arranged:
The retrospective is held after each conference. If conferences go one after another - their retrospectives can be combined. At the first stage, the list of detected problems and achievements is compiled into a single tablet in the internal wiki (we have Confluence). The list has several sources:
1. Own observations of team members. In our case, this is the richest source in terms of the number of points.
2. Feedback from participants. 70-80% of our participants leave us feedback after the conference. There are several hundred of them at each conference.
3. Feedback from the speakers - usually a couple of dozen reviews.
4. Feedback from sponsors - usually a few (5-10) reviews
5. Feedback from information partners
For points 2, 3 and 4, we use the online service SurveyMonkey. We used to use a simpler Google Forms, but have long outgrown it. More people use Typeform, but we do not like it yet - SurveMonkey will be more powerful. Each member of the team writes his own observations on a piece of paper or Evernote or something, then transfers it into a tablet with pens. The feedback from the information partners is collected by the employee of the marketing department tritely by e-mail.
In the resulting tablet we have several columns:
1. problem found / achievement. It is formulated in the form of some fact. For example, "bugs are often detected on mobile versions of our conference sites" or "there were no queues at last at the DotNext conference dinner."
2. The conference at which this problem (or achievement) was discovered. If the problem is systemic, we write not the conference name, but “All”.
3. The problem is, success is not clear. It is indicated by the plus, minus, or question mark icons, respectively.
4. Area of responsibility: what part of the event is associated with this item: Reports, Sites, Playground, Advertising, etc.
5. The author of this item. Every fighter enters here either himself or her beloved.
6. Solution of the problem. Before retrospective this field is not filled.
7. Ticket (task) in JIRA. Before the retrospective, this field is also not filled.
To fill the plate, we give two weeks. Then we move on to the second stage: the plate is cut into several pieces (usually again by areas of responsibility: marketing, equipment, playground, catering, reports) and each team responsible for the corresponding conference piece conducts a meeting, sorting out all the detected points and filling out the field "decision". The typical duration of a retrospective in each of our departments is from one to four hours.
Further, part of the decisions made during the retrospective show imply some actions on the part of the team members. After the retrospective, her presenter creates the corresponding tickets in JIRA and puts the numbers of these tickets in the last column of the table. A label “retrospective” is added to each of the tickets created after the retrospective. Everything, the retrospective is over: problems are spoken, conclusions are made, tickets are entered.
As a result, about 80% of the problems found we manage to solve within the department, without distracting colleagues from neighboring departments. In general, it is useful, a couple of months after the last retrospective, to conduct its third stage: reconvene in departments and look at the results. That is, go through the ticked notes marked “retrospective” and see which ones are solved, which ones do not exist yet, and which ones do not move at all. We are doing this third stage, to our shame, quite rarely and spontaneously. We ought to be more attentive to this issue.
But what to do in the case when several teams are involved in the problem at once? For example, when different requirements are received from different teams or do several teams have different opinions on a particular occasion? What to do when a team cannot independently work out a decision on a particular issue? Then you need to conduct a high-level retrospective. About her - in the next post.
----
Helpers:
1. SurveyMonkey online questionnaire service that we use to collect feedback: https://www.surveymonkey.com/
2. Book: Norm Kurt. Retrospective project. How project teams look back to move forward - edited by [id235585242 | Maxim Dorofe
1. See that we are good at the end of the project. And to understand why it turned out well: did we just get lucky or did we purposefully and systematically do something useful during the project that gave us the desired result?
2. To see what we are following as a result of the project is bad. And, of course, understand the causes of the problems found and draw the appropriate conclusions.
According to the results of the retrospective, all team members draw (well, or should do) certain conclusions that will make the next project better, whatever that means, “better” in each case.
How our jugrushnaya retrospective is arranged:
The retrospective is held after each conference. If conferences go one after another - their retrospectives can be combined. At the first stage, the list of detected problems and achievements is compiled into a single tablet in the internal wiki (we have Confluence). The list has several sources:
1. Own observations of team members. In our case, this is the richest source in terms of the number of points.
2. Feedback from participants. 70-80% of our participants leave us feedback after the conference. There are several hundred of them at each conference.
3. Feedback from the speakers - usually a couple of dozen reviews.
4. Feedback from sponsors - usually a few (5-10) reviews
5. Feedback from information partners
For points 2, 3 and 4, we use the online service SurveyMonkey. We used to use a simpler Google Forms, but have long outgrown it. More people use Typeform, but we do not like it yet - SurveMonkey will be more powerful. Each member of the team writes his own observations on a piece of paper or Evernote or something, then transfers it into a tablet with pens. The feedback from the information partners is collected by the employee of the marketing department tritely by e-mail.
In the resulting tablet we have several columns:
1. problem found / achievement. It is formulated in the form of some fact. For example, "bugs are often detected on mobile versions of our conference sites" or "there were no queues at last at the DotNext conference dinner."
2. The conference at which this problem (or achievement) was discovered. If the problem is systemic, we write not the conference name, but “All”.
3. The problem is, success is not clear. It is indicated by the plus, minus, or question mark icons, respectively.
4. Area of responsibility: what part of the event is associated with this item: Reports, Sites, Playground, Advertising, etc.
5. The author of this item. Every fighter enters here either himself or her beloved.
6. Solution of the problem. Before retrospective this field is not filled.
7. Ticket (task) in JIRA. Before the retrospective, this field is also not filled.
To fill the plate, we give two weeks. Then we move on to the second stage: the plate is cut into several pieces (usually again by areas of responsibility: marketing, equipment, playground, catering, reports) and each team responsible for the corresponding conference piece conducts a meeting, sorting out all the detected points and filling out the field "decision". The typical duration of a retrospective in each of our departments is from one to four hours.
Further, part of the decisions made during the retrospective show imply some actions on the part of the team members. After the retrospective, her presenter creates the corresponding tickets in JIRA and puts the numbers of these tickets in the last column of the table. A label “retrospective” is added to each of the tickets created after the retrospective. Everything, the retrospective is over: problems are spoken, conclusions are made, tickets are entered.
As a result, about 80% of the problems found we manage to solve within the department, without distracting colleagues from neighboring departments. In general, it is useful, a couple of months after the last retrospective, to conduct its third stage: reconvene in departments and look at the results. That is, go through the ticked notes marked “retrospective” and see which ones are solved, which ones do not exist yet, and which ones do not move at all. We are doing this third stage, to our shame, quite rarely and spontaneously. We ought to be more attentive to this issue.
But what to do in the case when several teams are involved in the problem at once? For example, when different requirements are received from different teams or do several teams have different opinions on a particular occasion? What to do when a team cannot independently work out a decision on a particular issue? Then you need to conduct a high-level retrospective. About her - in the next post.
----
Helpers:
1. SurveyMonkey online questionnaire service that we use to collect feedback: https://www.surveymonkey.com/
2. Book: Norm Kurt. Retrospective project. How project teams look back to move forward - edited by [id235585242 | Maxim Dorofe
У записи 10 лайков,
1 репостов,
875 просмотров.
1 репостов,
875 просмотров.
Эту запись оставил(а) на своей стене Алексей Федоров
