Как стать автором
Обновить

Комментарии 20

Да, полезно. Пишите ещё. В основе лежит довольно банальная идея, но когда видишь её со стороны — то лишний раз вспоминаешь, что действительно стоит это сделать.

Возможно для такого контента лучше подойдёт другая площадка (не реклама), vc.ru
Ну Хабр мне ближе по духу, но я пока еще в поиске своего формата.
Иногда сложно понять как это работает: в топе продуктового хаба висит статья о том, как парня кинули работодатели. Причем тут «управление продуктом»? Загадка.
Так что пока еще разбираюсь-осваиваюсь.
Нестареющая классика. Тоже использую везде, т.к. люблю ordnung и прозрачность/прослеживаемость, особенно в учете фич, заданий, заявок. Где-то гуглоэксель, где-то трелло. С экселем проблема одна — опасность, что кто-то случайно/специально затрет какие-то вещи. поэтому я ежедневно делаю бэкап таблички.
Много комментариев о том, что могут затереть данные.
Не знаю почему, но я вот вообще с этим никогда не сталкивался (хотя большинство доков ведем в таблицах).
Может быть дело в том, что почти всегда к таблице имеют доступ от 3 до 10 человек, кому это реально нужно.
Как бороться с вандализмом в табличках? Один юзер написал, второй пришел и по незнанию/специально стер информацию
Если речь про гугл-таблицы:
1. Если проблема реально актуальная — в гугл таблицах есть возможность настройки разных прав доступа к диапазону таблиц.
2. Если проблема редкая, то проще обнаружить доказательства через историю изменения ячеек — а потом придти к человеку и повыносить ему мозг (в зависимости от контекста — насколько жестко решать по месту) вопросами — а для чего ты это делал? А почему? А вот посмотри что мне теперь делать?

Кардинальное решение проблемы:
Каждому пользователю свой файл на редактирование, а остальные только на просмотр. Это неудобнее самому — так как надо еще файлы мержить, зато проблема решена на 100%
1. Есть права на редактирование всего или только чтение. Я что-то не припомню, чтобы юзер имел право редактировать только свое, но не мог редактировать соседское
В моем случае, доступ к таблице имеют только руководители отделов и у каждого – собственная вкладка. И это на 100% решает этот вопрос – за 3 года активного использования таблицы Improvements не было ни одного случая, когда что-то кому-то затерли.
Но даже если бы такое случилось – думаю просто восстановили бы нужную инфу из истории версий.

Другое дело, если доступ к таблице имеют сотни сотрудников – тогда да, наверняка будут проблемы. В таком случае нужна премодерация. Я это решаю так: сотрудники, у которых есть идея по продукту – пишут ее в чат продуктовых идей в slack. А продакт, который за это отвечает – тратит вечером 10-15 мин, чтобы выбрать толковые идеи и самостоятельно занести их в таблицу Ideas (заодно и раскидывает идеи по направлениям).

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


Или когда они хотят понять реальную очередь и приоритеты, понять предположительный срок решения их задачи.


Они умудряются затереть друг друга, используют разное оформление, пишут не то, что имеют в виду, ошибаются вкладками… В общем, за, я видел и организации, в которых вместо CRM — общая таблица в Excel (!).


Но в целом это плохая практика,, задачи стоит решать хорошими, заточенными под это инструментами. Google Sheets все же костыль, а не инструмент тут.

они не слишком грамотны, несколько ленивы или не очень хорошо организованы

У меня зачастую возникает вопрос а чего тогда такие люди делают на работе. Но вопрос этот риторический, и я замолкаю
Безусловно, для профессиональной работы именно с задачами – нужны нормальные инструменты. Мы для этого используем jira и confluence.

Но это инструменты для IT и Product отделов. А когда мы взаимодействуем с операционными отделами – то им намного проще оставить запрос в табличке, чем разбираться с оформлением таски в jira.

Что касается сроков реализации – то обычно внутренним заказчикам достаточно общих сроков типа «выливка будет в конце марта» или «задача вошла в следующий спринт».

А что делать с затиранием табличек – выше ответил. У нас такой проблемы нет от слова совсем. Хотя сейчас в компании под 200 сотрудников и 70% документации ведем именно в таблицах.

Знаете, была такая история…


все пчёлы прилетели в домашний улей с мёдом, а одна, вредная и противная — с каплей дёгтя

В общем, в семье не без паршивой овцы обычно, если вам везёт — это хорошо. Но рекомендовать другим рискованно.

А почему вместо этого не завести специальный проект в редмайне/джире где они бы делали о же самое?
Зачем для этого эксплуатировать таблицы?

кто будет настраивать и администрировать редмайн/джиру в неИТ конторе?

админ, которого в любом случае нужно нанять, чтобы не бегать с горящими жопами из-за первого же IT-факапа
(правда, нужно умудриться нанять нормального админа, что довольно тяжело когда оценивать некому)

В неИТ либо есть админ, либо внешний админ. И делается список задач в Битрикс24, например

Да, можно и в джире, конечно.
Статья больше о том, как сделать общение с заказчиками асинхронным, не требующим избыточного участия. А выбор инструмента вторичен.

Но мне есть, что сказать в защиту таблиц.

Во-первых, таблицы универсальны – все знают, как ими пользоваться и у всех есть gmail-аккаунт. Вы просто бросаете ссылку человеку, и он уже пользуется вашей таблицей.

Другое дело та же jira – она совсем не простая для человека вне IT. Попробуйте обучить сэйлза правильно оформлять задачу в джире – это будет не просто. И не потому, что сэйлз глупый, просто джира заточена под другие задачи, а сэйлз работает вообще в другом контексте. Ему придется специально заводить аккаунт только ради того, чтобы оставить вам запрос.

Мы даже пробовали нечто подобное – настроили Service Desk, который сам формировал задачи в джиру. Если сотрудник видел баг, то ему нужно было оформить его в Service Desk. Так вот, что удалось понять из этого эксперимента – большинство сотрудников не хотят таких заморочек. Когда человеку нужно прикладывать усилия, чтобы просто сообщить об ошибке в продукте – ему проще пройти мимо. Работают только простые инструменты – написать в чат или максимум в таблицу.

Во-вторых, таблицы реально удобные. Быстро грузятся, легко редактируются, можно совместно работать над документом. А в том же confluence (несмотря на мою любовь к нему) – совместная работа это тот еще головняк.

В третьих, таблицы достаточно надежные. Тут вот пишут, что могут случайно затираться данные – но я вообще с таким не сталкивался. Да и сохраняется все автоматически в облаке, с историей версий. А вот потерять карточку на общей доске Trello – проще простого.

В общем, мое мнение: специализированные инструменты хороши для персональной работы или работы в рамках одного отдела. А таблицы более универсальны и подходят для совместной работы разношерстных отделов в рамках большой компании.
На мой взгляд — инструмент хороший, но с достаточно узкой сферой применимости.
Если использовать ее в рамках основного процесса — и работать с ней каждый день, то это несерьезно. Надо что-то более специализированное и быстрое.
Если же реально использовать ее раз в несколько недель, то это оптимальное решение с точки зрения того, что оно настраивается за полчаса и потом работает. При этом процесс обучения минимален.
У кого есть опыт обучения пользоваться той же джирой людей в возрасте, которые никогда таск трекером не пользовались — поймут, что это та еще задача и таблицы для этого на порядок лучше.
Ну и из минусов я бы добавил — что если пользователи не могут нормально описать чего они хотят и какой Definition of Done, такой способ не сильно поможет.

Вопрос который у меня возник к автору:
А почему не использовать гугл-формы для заполнения? Тут и валидация, и не сломаешь никак — а доступ к результирующей гугл таблице можно дать только на просмотр и комментирование.

Да, про обучение сотрудников плюсую. Для людей вне IT, jira — это ад.

Про Definition of Done — я не ожидаю, что человек из финотдела, например, напишет запрос сразу в таком формате. На мой взгляд, это все-таки задача продакта — выявить реальную потребность, оценить нужно ли это делать, найти оптимальный вариант решения и оформить задачу как полагается.
Бывает, просят сделать какую-то фичу, а когда докапываешься до настоящей причины — оказывается это можно решить совсем иначе, значительно проще, а иногда и вовсе без разработки.

А гугл-формы — да, нормальный вариант, мы его тоже используем.
Но тут уже зависит от ситуации:
  • Если говорим о запросах от руководителей отделов, то они итак ничего не ломают, но могут дописать что-то важное в задачу по моей просьбе. А гугл-форма этого не позволяет.
  • Зато запросы на аналитику у нас сделаны именно так — заказчик оставляет запрос в гугл-форме, а потом может видеть свой запрос и ответ аналитика в таблице, которая доступна только для чтения.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории