Структурируй это!
Естественно, что все мы что-то делаем, чтобы эти данные структурировать. Я покажу, какие способы и инструменты использую я. Возможно, что-то вам покажется интересным.
Общие идеи
2. Не страшно если структура окажется не удачной, плохая структура лучше чем её отсутствие. Сделать хорошую структуру из плохой проще, чем хорошую и никакой.
3. Наличие структуры заранее – это хороший способ не создавать бардака в последующем. Например, имея одну папку в документации по проекту с названием "Техническая документация", класть затем счёт на первый уровень уже "не захочется", логично будет создать что-то вроде "Бухгалтерские документы".
4. Архивные данные тоже нуждаются в структурировании. Хоть это и не приятно, заниматься "бесполезной" работой по разбору того, что уже не актуально, это нужно делать. В противном случае эти данные просто "утонут" и когда они снова понадобятся (кто хоть раз делал готовые отчёты меня поймёт) приедятся тратить ещё больше времени. Часто архивные данные я структурирую менее детально, чем текущие, но это лучше, чем ничего.
5. Подход к структуре дело индивидуальное. Ассоциативная память штука крайне непростая. Деление, которое для одного удобно, совершенно не очевидно для другого. Тяжелее когда над данными необходимо работать совместно, но в нашей работе – это каждодневная необходимость. Тут сработает подход "Кому наиболее важно быстро находить информацию?". Например, проектная документация наиболее полезна для руководителя проекта, поэтому её структура должна быть такой, какая удобна ему. С бухгалтерскими документами всё может быть по-другому.
6. Не переусердствовать. Излишне глубокая структура тоже плохо. Я везде стараюсь не превышать без лишний необходимости 2-х уровней.
Почта
2. Пользуйся автоматическими фильтрами. Совет коррелирует с п. 1. Чем больше автоматических фильтров отсеивают вашу почту, тем лучше. Меньше лишних для работы писем в inbox, меньше времени тратиться на ручное структурирование. Сейчас уже все распространённые программы/сервисы для работы с почтой это позволяют. У меня в рабочей почте на данный момент 21 фильтр.
Исходный код
Нужно придерживаться одной идеологии в одинаковых сферах применения. Скажем, для веб-движка, должна быть одна структура хранения во всех проектах. И это должно относится не только к раскладыванию кода, но и к таким вещам, как, например, картинки и css.
Если используется фреймворк, часто он рекомендует или заставляет использовать определённую структуру. И её стоит придерживаться. Это сэкономит время на разъяснение структуры новым разработчикам, вместо этого их можно будет отправить читать соответствующий раздел документации. В фреймворках с принципом "соглашение ранее конфигурации", это ещё и экономит время на указание движку нестандартной структуры проекта.
Задачи
1. Собирать задачи в этапы. Этапы не имеют прямой связи с версией проекта. Иногда в одном этапе выпускается несколько версий, иногда версия длиться больше одного этапа. Это некоторое психологическое деление, которое удобно руководителю проекта. Все задачи в голове связываются с их этапом. Это позволяет затем проще в них ориентироваться ("а ... это было на этапе N, мы ещё тогда добавили классную фичу X и активно разрабатывали фичу Y, помню-помню"). Я больше помню развитие проекта в этапах, чем с привязкой к годам-месяцам. Иногда я начинаю этапы, по некоторым значимым событиям. Например, при переходе на GIT я сделал новый этап проекта.
2. Делить задачи по области влияния. В последнее время, я делю задачи именно так, а не по отношению к модулю или подсистеме. Грубо, это ответ "для чего это было сделано?", а не "где это было сделано?". Это удобнее для менеджеров проекта, потому что им не очень интересно, что вам пришлось внести изменение в класс X, куда более интересно им, что изменение было внесено для возможности Y.
3. Собирать задачи, включаемые в каждое обновление. В Ctool я для этого использую мета-задачи. В неё вставляю связи на все задачи которые в очередное обновление нужно включить, туда же добавляю информацию о том, какие ручные действия нужно выполнить при обновлении и какую информацию нужно сообщить менеджеру или заказчикам после обновления (например, написать, что готова фича X и её можно посмотреть там-то).
4. Писать задачу, даже если она не на 100% ясна. Если понятно, что задачу нужно будет делать, но пока не понятны детали, я заранее ставлю её в систему управления проектами и помечаю особым образом. Часто при этом у задачи есть только название, но нет ни описания, ни оценки, ни исполнителя. Такая задача служит напоминанием о том, что эти вопросы у кого-нибудь нужно уточнить.
5. Сначала общий план, потом конкретика. Это похоже на п. 4, но здесь задачи мне уже ясны. Но я вместо того, чтобы сразу бросаться описывать каждую задачу друг за другом, сначала ставлю их все с названием, оценкой, исполнителем, а уже затем расписываю. Таким образом я буду видеть общий план и необходимое время на реализацию какой-то многоэтапной фичи, а уже расписывать могу по мере выполнения задач.
6. Будущее тоже важно. Как я уже говорил, я веду этапы. Этап в Ctool – это мета-задача с кучей связных задач. При этом я всегда имею мета-задачу на следующий этап и часто даже на этап +2. А также имею спец. мета-задачу "Задачи на будущее" (т.н. backlog). Это позволяет мне проще отвечать на вопросы менеджеров или заказчиков "какие у вас среднесрочные/долгосрочные планы?". Я уже в общих чертах могу переставить, как будет двигаться проект.
Хаки
Быстрые пометки. Я использую хитрый хак, для пометок своих задач. Например все мета задачи я помечаю значком "⌘", не описанные до конца задачи - "~", бесконечные задачи - "∞" и т.д. Я стараюсь выбирать значки редко встречающиеся в названии задач (помогает таблица Unicode), чтобы потом по ним можно было строить удобные фильтры с поиском в названии задач.
Мета-задачи. Ещё один хак, которые я использую. Для каждой новой фичи я все связные задачи собираю в одну мета-задачу (с помощью связей к задачам в Ctool). В мета-задаче я могу быстро оценить готовность различных этапов, а также в комментариях вставлять важные замечания от заказчиков и менеджеров.
Часто конкретная задача нужна сразу для нескольких фич, тогда она будет включена в несколько мета-задач. В обратную сторону, по связям конечной задачи с мета-задачами, я могу быстро вспомнить для чего она нужна.
Comming soon
На этом я прервусь, чтобы затем вернуться со второй частью, где я планирую:
- рассказать о конкретных инструментах/сервисах, которые я использую;
- рассказать как я структурирую "умные мысли";
- рассказать как я структурирую информационно-новостной поток;
- привести некоторые полезные советы и вопросы самому себе, которые позволят оценить насколько хорошо продумана структура.
UPD: вместо двух частей будет целая серия заметок, смотрите соответствующий тег. Не переключайтесь!
