Описание проблемы
Все свои проекты я веду, конечно, в экзокортексе. На данный момент это Obsidian. Какое-то время назад я начал отмечать, что путаюсь в своих проектах. Выполняю их немного механически, "без огонька", то бишь понимания. Часто даже не понимаю, на какой вообще стадии они находятся. Это не несобранность и не "делание по привычке". Скорее, какое-то ментальное неудобство.
В тот момент, когда я описываю проект, я хорошо представляю, зачем он мне нужен. Могу не выражать данное понимание словами, но что-то такое в голове непременно есть. Это хорошо и правильно. Но я к тому же неявно считаю, что в любой момент в будущем я смогу всё это вспомнить в том же виде, что есть сейчас в моей голове. Однако, если верить моему же собственному опыту, заметную часть своих проектов я спустя какое-то время после начала продолжаю просто потому, что "надо же закончить", "я решил и сделаю" и прочее. Я уже не помню, зачем я делаю то или иное! Нет, конечно, я не упрямый маразматик, давно забывший о цели того, что делаю. Речь, скорее, о том, что до места в голове, содержащим информацию о цели моих действий, становится трудно добраться и поэтому я избегаю это делать.
Но это влечёт за собой отсутствие карты действий, с которой можно сверяться -- я всё ещё двигаюсь в правильном направлении или давно потерял цель (или она просто исчезла) и я просто иду, чтобы не стоять на месте? Представьте, что вы используете навигатор, включающийся раз в час -- сможете ли вы добраться с ним до цели?
Дойдя до данного места, я понял, что это что-то мне напоминает. Проект конечен. Он система обеспечения, имеющая жизненный цикл. Почитал экзокортекс, много думал…
Если у проекта (он же Система) есть жизненный цикл, тогда я делаю огромную ошибку, когда создаю в экзокортексе проект и сразу же пишу в нём, что и когда я хочу в этом проекте делать. Дело даже не в том, что я пропускаю начальные стадии жизненного цикла -- в момент добавления проекта в экзокортекс эти стадии у меня неформально в голове есть и я их как бы и не пропускаю. Я лишаю себя возможности свериться с маршрутом.
Риски
Вот то, что эти стадии никак не описаны, оставляет гигантскую дыру в системе безопасности проекта. Если мысленно представить себе чеклист для проверки завёршённости стадии "замысливание" или стадии "проектирование" у проекта "самолёт" или проекта "ремонт квартиры", то станет предельно ясно, чем я рискую, сразу приступая непосредственно к созданию проекта. То, что я могу его не закончить -- это полбеды. Я могу его не закончить триумфально, спустив в него кучу ресурсов -- в лучшем случае текущих, а в худшем -- ещё и будущих.
Получается, что, экономя на письменной обработке первых стадий проекта, я получаю следующие риски:
- замыслить проект, который окажется не нужен -- ведь я не зафиксировал, какую свою неудовлетворённость хочу закрыть или какую потребность удовлетворить;
- спроектировать систему, которая удовлетворяет не тот интерес, который мне нужно -- ведь я не убедился заранее в том, что знаю, как именно система будет работать на достижение цели;
- впустую потратить время, силы и другие ресурсы -- ведь у меня нет возможности с чем-то свериться и вовремя изменить или прекратить проект, если он окажется неактуален;
Отдельно стоит упомянуть про стоимость исправления ошибок ранних этапов. Чем позднее такие ошибки обнаруживаются, тем дороже их исправлять потом. То есть я, пропуская "ненужные" прямо сейчас этапы, закладываю под свои проекты бомбу весьма нехилых размеров.
Возможное решение
Вывод совершенно однозначен: лучше приложить "избыточные" усилия на всех без исключения начальных стадиях проекта, чем рисковать намного большими усилиями по исправлению ошибок. Что можно для этого сделать так, чтобы всё-таки минимизировать эти самые, якобы избыточные, усилия начальных стадий?
Для начала нам нужны критерии окончания первых стадий проекта. Примечательно, что критерии эти, в общем, весьма слабо зависят от предметной области проекта, то есть могут быть сформулированы единообразно. Если пользоваться такой "универсальностью" аккуратно и в каждом проекте дополнительно размышлять письмом над завершением этапа, то получится и практично, и экономично.
Например, так:
- Замысливание;
- Какую потребность закрывает проект?
- Какую систему для закрытия потребности я хочу построить?
- Каковы требования к системе?
- Какие ресурсы (время, деньги, материалы…) я готов выделить на построение системы?
- Проектирование;
- Какова Архитектура системы?
- Какие ограничения у системы? В каких точно условиях она применима?
- Каковы максимальные потери при создании и эксплуатации системы я могу себе позволить? Или, иначе, максимальная какова стоимость владения системой?
- Создание;
- Выполняет ли система все сформулированные требования?
Вообще это потянет за собой переосмысление моих проектов как таковых. Сейчас это проекты "сделать то", "изучить это", то есть нацеленные на делание дел и практик. А надо нацеливаться на изготовление целевой системы, удовлетворяющей какой-то мой интерес, и далее отслеживать прогресс согласно жизненному циклу проекта.
Выиграю я от этого то, что я буду знать цель проекта (точнее, целевую систему!). Это позволит быстрее и точнее их замысливать, писать требования, назначение системы и т.п. И ещё вовремя утилизировать ставшие неактуальными проекты.
Дополнения
Является ли проектом чтение сложного текста?
Является ли "проектом" чтение толстой и сложной книжки? Я предполагаю, что да:
- я читаю толстую и сложную книжку не просто так, а ради чего-то. Что-то удовлетворяю в себе. Кстати, перечитывая любимую художественную книжку, я тоже закрываю какую-то потребность и, если её осознать, то это понимание может стать большой неожиданностью;
- когда я читаю книгу, я часто явно понимаю, какие изменения я желаю произвести в себе. Создать новое умение, создать или воспроизвести в себе чувство или ощущение. То есть целью проекта является построение определённого физического или ментального 4D-объекта.
- к данному объекту я заранее предъявляю какие-то требования. И накладываю на него ограничения, см. ниже.
- я читаю не абы какую книгу. Я предъявляю к ней набор требований: "чтобы интересно было", "чтобы писали без воды и отсебятины" и так далее. Даже "чтобы провести время" -- тоже требование!
- на чтение действительно нужной книги я готов выделить ежедневное время, заплатить за неё деньги и т.п.
- с архитектурой создаваемой при чтении системы я пока не совсем понимаю. Предположу, что это то, как должно работать создаваемое умение. Например, научиться печатать на клавиатуре вслепую путём вхождения в гипнотический транс -- немного не то архитектурное решение?
- с ограничениями всё совсем интересно:
- при замысливании/проектировании той системы, ради которой я затеял чтение книги, я могу потратить на само это чтение такое-то время, такие-то деньги и, возможно, что-то ещё;
- однако помним, что чтение книги только создаёт систему! Запросто может случиться, что книга создаёт не то, что мне надо. А откуда я это знаю? У меня в голове есть какие-то требования к создаваемой системе? Значит, надо вытащить их наружу -- возможно, это быстрее поможет осознать, что книга "не про то".
По факту, все вышенаписанное про книгу как проект приводит к тому, что получаем каркас рецензии на книгу. Её стоит начать писать до того, как станешь читать книгу -- это поможет максимально быстро понять, осмысленно ли её дочитывать и почему, а также подвести итог прочтению.
Данная заметка -- тоже проект
Примечательно, что в конце написания данной заметки меня настигло осознание того, что сама эта заметка тоже проект. Вероятно, нет смысла в начале каждого текста разворачивать всю громоздкую структуру описания целей, ограничений и требований, но вот иметь в виду и быть готовым развернуть подобные описания точно не будет лишним:
Какая неудовлетворённость привела к заметке? Я путаюсь в своих проектах. Это не несобранность -- скорее незнание протокола работы с проектами как таковыми.
Какую систему для закрытия неудовлетворённости я хочу создать? Знание того, как лучше работать с проектами на ранних стадиях, поддержанное изменениями в экзокортексе. Если знать, какой из моих текущих проектов в какой фазе этого цикла находится -- это разгрузит внимание, так как заранее понятно, на что смотреть в первую очередь в той или иной фазе.
Какие требования к системе? Обеспечить понятность и однозначность замысливания, проектирования и создания моих проектов. Выиграю я от этого то, что я буду знать цель проекта (точнее, целевую систему!). Это позволит мне в темпе писать цель проекта: требования, ограничения системы и т.п.
Каковы ограничения при использовании системы? Она должна отнимать не более 10-20% ресурсов, отведённых на проект.