Выпуск 9. Структурируй это! - часть 1

Спец. выпуск в двух частях.

Структурируй это!

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

Естественно, что все мы что-то делаем, чтобы эти данные структурировать. Я покажу, какие способы и инструменты использую я. Возможно, что-то вам покажется интересным.

Общие идеи

1. Структура ранее наполнения. Я всегда стараюсь придумать некоторую структуру для хранения данных до того, как большие объёмы информации начинают поступать. Это может быть, как горизонтальное структурирование (теги, даты документа, номера договоров  ...), так и вертикальное (дерево папок).

2.  Не страшно если структура окажется не удачной, плохая структура лучше чем её отсутствие. Сделать хорошую структуру из плохой проще, чем хорошую и никакой.

3. Наличие структуры заранее – это хороший способ не создавать бардака в последующем. Например, имея одну папку в документации по проекту с названием "Техническая документация", класть затем счёт на первый уровень уже "не захочется", логично будет создать что-то вроде "Бухгалтерские документы".

4. Архивные данные тоже нуждаются в структурировании. Хоть это и не приятно, заниматься "бесполезной" работой по разбору того, что уже не актуально, это нужно делать. В противном случае эти данные просто "утонут" и когда они снова понадобятся (кто хоть раз делал готовые отчёты меня поймёт) приедятся тратить ещё больше времени. Часто архивные данные я структурирую менее детально, чем текущие, но это лучше, чем ничего.

5. Подход  к  структуре дело индивидуальное. Ассоциативная память штука крайне непростая. Деление, которое для одного удобно, совершенно не очевидно для другого. Тяжелее когда над данными необходимо работать совместно, но в нашей работе – это каждодневная необходимость. Тут сработает подход "Кому наиболее важно быстро находить информацию?". Например, проектная документация наиболее полезна для руководителя проекта, поэтому её структура должна быть такой, какая удобна ему. С бухгалтерскими документами всё может быть по-другому.

6. Не переусердствовать. Излишне глубокая структура тоже плохо. Я везде стараюсь не превышать без лишний необходимости 2-х уровней.

Почта

1. Держи inbox пустым. "Входящие" – это показания к действию, то что вам нужно делать. Всё остальное должно быть спрятано в архив, а лучше разложено по папкам.

2. Пользуйся автоматическими фильтрами. Совет коррелирует с п. 1. Чем больше автоматических фильтров отсеивают вашу почту, тем лучше. Меньше лишних для работы писем в inbox, меньше времени тратиться на ручное структурирование. Сейчас уже все распространённые программы/сервисы для работы с почтой это позволяют. У меня в рабочей почте на данный момент 21 фильтр.

Исходный код

С исходным кодом проектов чуть-чуть другая история. Но тут тоже работает правило  "Кому наиболее важно быстро находить информацию?" хотя и в немного перекошенном виде.

Нужно придерживаться одной идеологии в одинаковых сферах применения. Скажем, для веб-движка, должна быть одна структура хранения во всех проектах. И это должно относится не только к раскладыванию кода, но и к таким вещам, как, например, картинки и css.

Если используется фреймворк, часто он рекомендует или заставляет использовать определённую структуру. И её стоит придерживаться. Это сэкономит время на разъяснение структуры новым разработчикам, вместо этого их можно будет отправить читать соответствующий раздел документации. В фреймворках с принципом "соглашение ранее конфигурации", это ещё и экономит время на указание движку нестандартной структуры проекта.

Задачи

Сразу оговорюсь, что я имею дело с проектами, длящимися годами. Поэтому мой подход может отличаться от того, который удобен при создании сайта за 3 месяца.

1. Собирать задачи в этапы. Этапы не имеют прямой связи с версией проекта. Иногда в одном этапе выпускается несколько версий, иногда версия длиться больше одного этапа. Это некоторое психологическое деление, которое удобно руководителю проекта. Все задачи в голове связываются с их этапом. Это позволяет затем проще в них ориентироваться ("а ... это было на этапе N, мы ещё тогда добавили классную фичу X и активно разрабатывали фичу Y, помню-помню"). Я больше помню развитие проекта в этапах, чем с привязкой к годам-месяцам. Иногда я начинаю этапы, по некоторым значимым событиям. Например, при переходе на GIT я сделал новый этап проекта.

2. Делить задачи по области влияния. В последнее время, я делю задачи именно так, а не по отношению к модулю или подсистеме. Грубо, это ответ "для чего это было сделано?", а не "где это было сделано?". Это удобнее для менеджеров проекта, потому что им не очень интересно, что вам пришлось внести изменение в класс X, куда более интересно им, что изменение было внесено для возможности Y.

3. Собирать задачи, включаемые в каждое обновление. В Ctool я для этого использую мета-задачи. В неё вставляю связи на все задачи которые в очередное обновление нужно включить, туда же добавляю информацию о том, какие ручные действия нужно выполнить при обновлении и какую информацию нужно сообщить менеджеру или заказчикам после обновления (например, написать, что готова фича X и её можно посмотреть там-то).

4. Писать задачу, даже если она не на 100% ясна. Если понятно, что задачу нужно будет делать, но пока не понятны детали, я заранее ставлю её в систему управления проектами и помечаю особым образом. Часто при этом у задачи есть только название, но нет ни описания, ни оценки, ни исполнителя. Такая задача служит напоминанием о том, что эти вопросы у кого-нибудь нужно уточнить.

5. Сначала общий план, потом конкретика. Это похоже на п. 4, но здесь задачи мне уже ясны. Но я вместо того, чтобы сразу бросаться описывать каждую задачу друг за другом, сначала ставлю их все с названием, оценкой, исполнителем, а уже затем расписываю. Таким образом я буду видеть общий план и необходимое время на реализацию какой-то многоэтапной фичи, а уже расписывать могу по мере выполнения задач.

6. Будущее тоже важно. Как я уже говорил, я веду этапы. Этап в Ctool – это мета-задача с кучей связных задач. При этом я всегда имею мета-задачу на следующий этап и часто даже на этап +2. А также имею спец. мета-задачу "Задачи на будущее" (т.н. backlog). Это позволяет мне проще отвечать на вопросы менеджеров или заказчиков "какие у вас среднесрочные/долгосрочные планы?". Я уже в общих чертах могу переставить, как будет двигаться проект.



Хаки

Быстрые пометки. Я использую хитрый хак, для пометок своих задач. Например все мета задачи я помечаю значком "⌘", не описанные до конца задачи - "~", бесконечные задачи - "∞" и т.д. Я стараюсь выбирать значки редко встречающиеся в названии задач (помогает таблица Unicode), чтобы потом по ним можно было строить удобные фильтры с поиском в названии задач.

Мета-задачи. Ещё один хак, которые я использую. Для каждой новой фичи я все связные задачи собираю в одну мета-задачу (с помощью связей к задачам в Ctool). В мета-задаче я могу быстро оценить готовность различных этапов, а также в комментариях вставлять важные замечания от заказчиков и менеджеров.

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

Comming soon

На этом я прервусь, чтобы затем вернуться со второй частью, где я планирую:

• рассказать о конкретных инструментах/сервисах, которые я использую;
• рассказать как я структурирую "умные мысли";
• рассказать как я структурирую информационно-новостной поток;
• привести некоторые полезные советы и вопросы самому себе, которые позволят оценить насколько хорошо продумана структура.

UPD: вместо двух частей будет целая серия заметок, смотрите соответствующий тег. Не переключайтесь!