x
 
Олег Матяш
15 мая 2019
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

В ведре одного из кейсов бюро увидел, как вы использовали гугль-док, чтобы упорядочить командное обсуждение. Нам понравилось, думаем попробовать так же. Наверное, сейчас вы такие задачи решаете в Бейскемпе. У вас есть какие-то универсальные шаблоны, правила управления обсуждением? Какие плюсы и минусы решения такой задачи в гугль-доках?


Олег!

В бюро нет жёст­ких тре­бо­ва­ний к тому, где и каким именно обра­зом вести задачи и баги раз­ра­ботки. Глав­ное, чтобы задачи не поте­ря­лись и были на виду у дизай­не­ров, а раз­ра­бот­чики хорошо себе пред­став­ляли, что нужно сделать.

Напри­мер, бюро­ш­ные раз­ра­бот­чики само­сто­я­тельно запи­сы­вают баги в Бей­скемпе в виде туду­шек по резуль­та­там уст­ных и пись­мен­ных обсуж­де­ний, а неко­то­рые кли­ент­ские раз­ра­бот­чики допол­ни­тельно ведут свои списки в дру­гих при­выч­ных им систе­мах. Ну а я в своих про­ек­тах исполь­зую гугль‑доки. Точно не помню, когда и почему я это начал делать, но ока­за­лось удобно.

Во‑пер­вых, объ­яс­не­ние «пра­вил игры» зани­мает не больше минуты уст­ного раз­го­вора или несколь­ких строк тек­стом, а интер­фейс гугль‑дока все уже и так знают. Во‑вто­рых, всё на виду и очень наглядно: гугль‑док пре­вра­ща­ется не про­сто в спи­сок, а почти что про­гресс‑бар про­екта — чем больше зелё­ного, тем ближе успех. В‑тре­тьих, выдача доступа кому бы то ни было зани­мает секунды — не нужна ника­кая реги­стра­ция, в отли­чие от того же Бей­скемпа. В‑чет­вёр­тых, всё хра­нится вечно и без необ­хо­ди­мо­сти пом­нить допол­ни­тель­ные пароли и адреса. В‑пятых, да, оно бесплатно.

Как это работает

С самого начала заво­дятся два списка: «Задачи» и «При­ня­тые». В пер­вый дизай­неры пишут баги, про­блемы и задачи, во вто­рой — пере­но­сят решён­ные задачи:

Начи­на­ется раз­ра­ботка, появ­ля­ются баги и хотелки, всё зано­сится в доку­мент. В слож­ных и раз­но­пла­но­вых про­ек­тах лучше груп­пи­ро­вать задачи с помо­щью заголовков:

Раз­ра­бот­чики про­дол­жают пилить функ­ци­о­нал и в какой‑то зара­нее согла­со­ван­ный момент при­ни­ма­ются за исправ­ле­ние багов. Исправ­лен­ные баги они выде­ляют зелё­ным цве­том, а те, что ещё нахо­дятся в работе, — мно­го­то­чием в начале строки или ещё каким‑то способом:

Дизай­неры допи­сы­вают новые баги и при­ни­мают исправ­лен­ные. При­ня­тые баги они про­сто зачёр­ки­вают, не при­ня­тые выде­ляют оран­же­вым цве­том и пояс­няют с помо­щью обыч­ных ком­мен­та­риев гугль‑дока:

Кстати, любой баг хорошо бы допол­нять скрин­шо­том или ссыл­кой, но для ско­ро­сти в своих при­ме­рах я решил обой­тись без них.

Раз­ра­ботка про­дол­жа­ется, баги появ­ля­ются, опи­сы­ва­ются и исправ­ля­ются. Слож­ные слу­чаи и непо­нят­ные про­блемы обя­за­тельно про­го­ва­ри­ва­ются устно. В какой‑то момент исправ­лен­ных и при­ня­тых багов ста­но­вится так много, что пора пере­но­сить их в спи­сок «Принятые»:

При­бли­жа­ется время пуска и при­хо­дится рас­став­лять при­о­ри­теты. Горя­щие и бло­ки­ру­ю­щие пуск задачи дизай­неры выде­ляют красным:

Раз­ра­бот­чики сде­лали рывок и за день попра­вили кучу всего. Много зелё­ного моти­ви­рует и дизай­не­ров, и самих разработчиков:

И так далее до пуска.

Из неудобств работы в гугль‑доке полу­ча­ется при­пом­нить только одну вещь: очень долго пере­но­сить при­ня­тые баги в ниж­ний список.

Напо­сле­док ещё один скрин­шот. В одном из про­ек­тов раз­ра­бот­чики из ком­па­нии «Цифро­но­мика», парт­нёра бюро, при­ду­мали объ­яс­нять всё опи­сан­ное выше с помо­щью легенды, кото­рая добав­ля­ется в самом начале работы:

Если хотите попро­бо­вать, вос­поль­зуй­тесь моей заго­тов­кой гугль‑дока.

При­гла­шаю ува­жа­е­мых совет­чи­ков поде­литься сво­ими сек­ре­тами и фиш­ками управ­ле­ния разработкой.

Типографика и вёрстка — дисциплина Школы дизайнеров. Набор открыт до 12 августа или пока есть свободные места.
 

Поделиться
Отправить

Комментарии

Никита Рвачев
15 мая 2019

Касательно неудобства переноса пунктов — стоит попробовать Notion. Там как раз этот вопрос решён.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Как донести подход HADI до руководства? 4 Как резать фичи на основе экспериментов? 3 Советы об управлении разработкой Как в бюро ставят задачи? 6




Недавно всплыло

2 4 2 2