Работает ли у вас ГТД?

ГТД - это какая-то нерабочая хрень

На абрамсах таки ГТД. И утверждать, что она совсем уж не работает — как-то глупо.

Чтобы GTD работало, нужно навести порядок в голове.

Как таковой GTD — это умение эффективно распоряжаться своим временем, и пока у тебя в голове бардак, эффективно ты вряд ли что-то сможешь делать.

Мне для этого даже списки не нужны, так как они сами по себе отнимают время на их составление и редактирование.

папка на рабочем столе, куда скиданы все относящиеся к делу вещи, и заодно список дел, иногда несколько списков

Что-то среднее между мусорным ведром и могилой, да? :D

У тебя недостаток внимания от окружающих?

Скорее, переизбыток

GTD работает, особенно по схеме от «Успеватель Василия Кислого». Открой для себя Emacs org-mode и ты постигнешь путь к ДАО. Задачи могут содержать ссылки на любые сущности.

Задачи могут содержать ссылки на любые сущности.

Предположим, это будет ссылка на папку. Но если она будет перемещена, ссылка будет сломана.

Но вообще спасибо за информацию.

Или даже не перемещена, а хотя бы переименована.

Ты таки дрочишь папки в компьютере, или чем-то полезным занимаешься irl?

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

Тетрадка? Авторучка?

Возьми продвинутую версию GTD под названием канбан.

Это работает в проде у половины мира, в тч серьезных организациях.

Если ты такой олдфаг, можешь канбан-доску повесить на стену, настоящую.

Если менее олдфаг, то взять ту что встроена в JIRA, или kaiten.io (у них бесплатный триал есть чтобы понять, что такое канбан), или любой другой софт для электронной канбан-доски

Если ты программист, то колонки можно такие: бэклог, todo, design (аналитика, обдумывание, итп), development, testing, done.

Для непрограммистов хватит просто бэклог, todo, in progrss, done (это дефолтная раскладка в JIRA)

Как работать по канбан-доске, наверное, написано в миллионе книжек, но щаз по-быстрому не придумаю. Лучше что-нибудь прочитать, чтобы понять смысл канбана. В гугле все есть.

GTD как раз сделан для того, чтобы «порядком» не занимать ресурсы мозга

твоя «осознанная» деятельность - это только наполнение бэклога (включая quick time events на добавление новых задач), дальше берет на себя Система

Покупка тетрадка и авторучка, а потом выполнение «домашки» - это был шуточный пример проекта, в том виде, в который его обычно пытаются «загнать» в программах типа https://www.mylifeorganized.net/. Я имел в виду, что подобная «однострочность» неудобна.

Канбан для тебя работает?

газотурбинный двигатель? нет.

они сами по себе отнимают время на их составление и редактирование

этож нью генерейшн, у них есть время на составление списков

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

ГТ1 тоже таскает вагоны понемногу. Вполне рабочая хрень.

хочется сразу где-то делать заметки о нюансах, сложностях, мысли на тему

MongoDB или другая нереляционка тебя спасет. Прикрути к ней шкурку на чем умеешь и пользуйся.

Турбинодебилы традиционно сосут у дизелебогов. Турбины мертвы, после Т-80 и Абрамса больше никто их ставить в танки не планирует.

Возьми продвинутую версию GTD под названием канбан.

Пользуюсь Trello, например. Наверное это самый популярный канбан, да? Неудобно.

* Если вести списки по классике, т.е. planned > in progress > done, то первый и последний получаются очень длинными, долго скроллить.

* Поскольку у карточки нет состояния «Выполнено», отсуствует любая статистика. Меня, например, она мотивирует.

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

* Поиск - говно. Тэги только по цветам. Списки удалять нельзя.

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

Признаюсь честно, я пользуюсь JIRA пока. Хоть и проприетарщина. Это более сложная концепция, она подходит как раз для тех, кто столкнулся с продвинутыми проблемами.

В JIRA есть концепция «бэклога», доставшаяся из Аджайла. Бклог - это в термнах Трелло - скрытый list, в котором дофига всего, и который обычно смотрят на отдельном экране. Бэклог структурируется Epic (эпиками) - отдельными тематическими коллекциями. Например, при разработке статей для журналов, можно выделить по эпику для каждого заказчика: «статьи для Васи за декабрь».

Это всё стандартная терминология Аджайла (в скраме итп будет то же самое почти)

Бэклог можно не отображать на канбан-доске.

То есть первая колонка - это скорей не planned, а todo, ближайший аналог inbox с фильтром по «current tasks» из GTD. Не нужно забивать сразу тысячами задач. Туда переносится только то, что реально сейчас в фокусе внимания.

Колонку in progress лучше поделить на концептуальные части. У каждого они свои. Например у меня задача обычно состоит из таких этапов: design (обдумывание и сбор материала), development (например, написание статьи в блог), testing (отправка статьи на проверку корректорам, отправить друзьям на оценку), publishing (публикация в блоге, шаринг по соцсетям), done.

При переводе в done, задача всегда маркируется меткой - к какому продукту какой еще невыпущенной версии оно относится.

После того как ты выполнил достаточно связанных по смыслу задач, нужно надавать кнопку Release и выпустить релиз своего продукта. У меня это обычно «Статьи за декабрь», или инкремент версии продукта: «Textorio v15.

После нажатия кнопки Release, все зарелизенные задачи с доски исчезают.

Таким образом, у тебя полуается как раз идеальное GTD. На доске - только то, что сейчас в фокусе внимания. Всё остальное берет на себя Система.

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

Не соглашусь. GTD хорош, когда ты - обычный человек, ведущий парочку проектов типа «не забыть купить молоко».

Когда у тебя десятки параллельных задач, идущих все одновременно, с подходом «инбокс размером шесть листов A4» тебе капец =)

Примеры людей, у которых такое:

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

- opensource разработчики с мелкими коммитами в 3-4 строчки в кучу проектов, итп

- любые самозанятые предприниматели, когда ты сам себе ИП и выполняешь роль сразу всех: и продажника, и бухгалтера, и «представительского лица», и человека делающего всю работу руками, итп

Если у тебя инбокс на шесть листов A4 мелким почерком, и в нем нет никакой структуры - это кошмар кошмар ужас ужас. Это либо хаос, либо нужно загрузить всё в голову одновременно. А одновременно загрузить в голову - это а) против идеи GTD б) кошмар кошмар ужас ужас кровь кишки расчлененка. Смотришь на инбокс, и тебе реально физически страшно от такого объема.

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

Ну и понятно, что при этом время на логирование действий становится совершенно неприличное, что прямо противоположно идее GTD. Добавление и менеджмент нового таска не должны отвлекать от выполнения.

Кстати, в трелло есть грязный хак. Можно сделать отдельную доску под «архивные версии». Выпуск релиза можно симулировать переносом задачи из списка Done в эту архивную доску. Но придется делать это руками, ибо групповые операции над тикетами в Трелле есть только в платной версии (а если ты можешь купить платную версию, то почему бы не купить джиру или какой-нибудь kaiten.io)

если не нужная групповая работа можно тупо пересесть на Эксель (либреофис не пробовал, к сожалению - наверное в кальке тоже можно)

Спасибо тебе большое за этот пост.

Это более сложная концепция, она подходит как раз для тех, кто столкнулся с продвинутыми проблемами.

Ты так витиевато на ожирение своё намекаешь?

Турбинодебилы традиционно сосут у дизелебогов. Турбины мертвы, после Т-80 и Абрамса больше никто их ставить в танки не планирует.

Вот не надо тут ударяться в сравнения, речь шла о рабочести ГТД. И два крутых танка, построенных двумя супердержавами — наглядное доказательство того факта, что ГТД вполне себе работает. Даже если дизель в итоге выиграет.

Т.е. на самом деле за предыдущий, но и за этот тоже)

Коньбан рили работает там, где сильно думать не надо — т.е. уже подумали за тебя и разбили на знакомые куски, которые никогда не меняются (т.к. придумано в автопроме на конвейере :)).

На индивидуальном уровне это сводится к колонкам to-do (от бэклога не отличается ничем, что не туду вообще на доску не попадет, а чо прямо щас не делаешь — об том и беспокоиться сильно не надо, потому что оно может быть очень важно седня, а завтра не очень — потому что «бизнес пришел с новой идеей» сломал все расписание, хочется их всех убить), work-in-progress, done, бэклог обычно растет и растет :) Остальные вариации на тему стадийности — либо для отражения взаимодействия с другими участниками процессов, либо для... имитации наличия процессов, которые все игнорируют легко и непринужденно при первой же возможности (особенно заказчики «воу-воу, у вас процесс? а у нас бабло и сроки!»)

Правда в том, что это все костыли для неорганизованных распустех и их руководятлов (особенно для вторых — хотя бы видно какая ИБД происходит где и о чем... хотя залепуху гнать могут и тут, легко и непринужденно — сами же руководятлы).

GTD как раз сделан для того, чтобы «порядком» не занимать ресурсы мозга

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

твоя «осознанная» деятельность - это только наполнение бэклога (включая quick time events на добавление новых задач)

Я пробовал заменить бумажный ежедневник taskwarrior и прочими task-приложениями, но всё это требует слишком много телодвижений и не особо переносимо и кроссплатформенно. Учитывая, что я не пользуюсь смартфонами (слишком сложные в управлении, быстро садится батарея, сенсорным экраном невозможно пользоваться на ходу), приемлемых решений нет, кроме бумажного блокнота-ежедневника.

дальше берет на себя Система

Система работает только пока ты работаешь на неё. Это времязатратно.

дальше берет на себя Система

Лол, это если ты работаешь в Системе, которая от результатов твоих телодвижений не зависит. Особенно если есть кому подумать что делать и как :) А если нет — придется епта голову включать. Иначе эта ИБД ниочем и выродится в висящие таски, которые никто не понимает как делать, или в бурное движение по доске с нулевым выхлопом.

Попытаюсь дать дилетансткий совет: попробуй всё, что предложат, и оставь то, что работает. Я два года пытался пользоваться Kanban в виде Trello; понял, что ошибался, не подходит. Жена упорно заставляла меня использовать ежедневник, бумажный. Я постоянно забывал в него смотреть. В итоге у меня сработало следующее: я установил себе на VPS Nextcloud и завёл там календарь, для личных дел. Для бэклога задач на работе использую систему регистрации тикетов(исторически это был OSTicket, скоро перелезем на Jira), но для того, чтобы отмечать прогресс за текущий день, я использую тетрадку и ручку. В тетрадке я делю лист пополам; в правой половине я пишу список задач на сегодня с расстановкой приоритетов, в левой половине я пишу лог с отметками времени(нужно следить за тем, сколько уходит на выполнение разнообразных задач). Помимо отслеживания прогресса я вижу ещё несколько положительных побочных эффектов:

• У меня всегда есть что сказать на стендап-митинге, список перед глазами
• У меня не маячит перед глазами весь этот огромный список задач из всего, что надо сделать, соответственно, я не пугаюсь и это меня не демотивирует
• Невыполненные задачи с приоритетом пониже можно перенести на следующий день, а зачёркнутый список на сегодня оставит ощущение того, что все пункты просмотрены и обработаны

В общем, смотри, пробуй, не бойся экспериментировать и не стесняйся выкидывать то, что не работает. Удачи!

У меня всегда есть что сказать на стендап-митинге, список перед глазами

У меня нет стендап митингов — и чет работа делается :)

Да кто бы сомневался с таким подходом :) Свалки быть не должно. Побей всё на эпики, в эпиках выдели юзерстори. Пойми разницу между эпиком и юзерстори. Карточки промаркируй релизами, релизы надо действительно выпускать. Между карточками проставь связи типа «блокирует», «заблокировано», «связано», «является подзадачей», итп.

Когда заказчик прибегает с новыми фичами - фигачь новые юзерстори и эпики. При этом важно с берега договориться с бизнесом, что вы работаете именно по канбану и никак иначе. В рамках канбана, предполагается специальная «производственная линия» на «задачи от бигбоссов» с большим приоритетом и срочностью. Емкость этой линии заранее обговаривается с бизнесом, например - не больше 1 задачи в линии. Или 3. Если линия заполнилась - бизнес ждёт. Это нерушимое правило #1. (При этом в эпик можно напихать задач сколько угодно - это не значит, что они встанут в приоритетную линию). Этот подход - это классика канбана, кстати.

Канбан - это о том, что ты решаешь стандартные проблемы. Он как раз создан для того, чтобы было визуально видно проблемы типа «много work in progress».

Самоорганизующаяся команда (типа нашей) или руководятел (в случае рабско-ориентированной) может просто бросить больше сил на development. Или может быть, куча задач в разработке потому, что их не успевают принять тестировщики, и перед тестированием образовался затор - тогда надо бросить силы на тестирование.

Канбан-доска - это инструмент для визуального контроля таких вопросов. С целью, например, оптимизации скорости проплывания фич по трубе.

Для R&D проектов кабан больше подходит, чем для серийных. Серийное - это скрам, когда ты уверен что к концу спринта ты что-то сделаешь. А что делать, если ты не уверен, что сделаешь хоть что-то - ни за спринт, ни за два? А в канбане задача может валяться хоть месяц. (Чтобы они там не загнили, есть специальные методики).

Короче, чините свой канбан.

Можете меня в следующем году пригласить =) Я как раз буду на аджайл-коуча сертифицироваться, нужно несколько команд для «защиты диплома».

Спасибо, в целом ценно.

выродится в висящие таски

одна из основных целей - оптимизация скорости и равномерности проплывания тасок по трубе. Для этого существует несколько основных метрик, которые в виде графиков есть на любой канбан-доске

если если несколько тасок, которые висят долго (или одна, висящая вечно) - это сразу будет видно по графику.

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

удар по KPI выражатеся в ударе по вариативной части зарплаты (премии) или других ништяках. А премия у тебя, допустим, две трети зарплаты.

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

и да, в R&D есть таски, которые никто не понимает как делать, и возможно - никто и не поймёт никогда =) Это нормально

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

Я может у тебя возьму урок по скайпу, если самостоятельно не выгорит =)

Эпики-хуЭпики. Все это суета и смятенье духа. Нормальный сетевой график составлять кому надо умели еще давно.

Самоорганизующаяся команда (типа нашей) или руководятел (в случае рабско-ориентированной)

Никакие методики не работают сами по себе :) Ну придумали вы себе доп. работу по перетаскиванию тасок по доске — просто форма софт-контроля, «выпас котов». Некоторые над армией смеются — а вы к этому сами идете.

может просто бросить больше сил на development.

Угу, «играющий вратарь может больше времени бросить на игру в нападении» — некоторые используют канбан потому, что наоборот «хотят соседоточицца на управлении проэктом» — поэтому им и нужны «самоорганизовывающиеся команды» :) Желательно из неженатых хикки.

Для R&D проектов кабан больше подходит, чем для серийных.

Само R&D вобще никак не завязано на аналитегу «чо происходит». Потому что на доске сути происходящего нет и не будет :)

Короче, чините свой канбан.

Эта мода как пришла так и уйдет. Кто дела делал — тот и дальше будет делать, а кто не делал — и на твой канбан насыпет горку болтов.

Кэп, ты такой кэп :) KPI твои рисуются какие надо за пять минут — ни одна описаная тобой ИБД не поможет, если знать как ее нае*ть :)

по вариативной части зарплаты (премии) или других ништяках

Сказки про морковку спереди и сзади работают ровно до итальянской забастовки тех кто в теме про реальную борьбу копетализдов «с сокращением издержек» — к которым относится даже твоя зп :)

«Раньше» было проектное управление и годовые планы. Сейчас аджайл, и планов нету - есть векторы развития. Канбан и проектное управление - не сочетаются

В аджайле все команды - кроссфункциональны. Программист должен уметь и тестировать, и аналитить (но делать это будет хуже), аналитик или администратор - должен чуть хуже тестировать, и совсем плохо программировать (но хоть как-то - должен). И так далее.

«Намного хуже», «чуть хуже» - это количественные характеристики, использующиеся при планировании. Грубо говоря, можно каждого человека в «своей» специальности можно оценить на 10 пунктов производительности из 10, но при переносе в «чужую» колонку - он становится 5 пунктами (как программист ставший тестером) или 1-2 пунктами (как аналитик, перешедший в программисты). Конкретные попугаи устанавливаются опытно, могут меняться со временем, постоянные численные замеры - как раз дело менеджмента.

Таким образом, если например программер Вася видит, что тестировщик Петя слишком медленно тестирует, он понимает: из-за Пети его зарплата может стать на треть меньше. Или на две трети. И у него возгорается жопа! И у него есть множество путей - он может попросить другого разраба Диму помочь, и пойти тестировать - каждый из разрабов это полтестировщика, вместе получается 1 тестировщик. Или попробовать взять те задачи, которые еще не отданы на тестирование, и сделать их более просто тестируемыми. Или напимсать для Пети какие-то тулзы, которые ускорят ему тестирование (например, улучшить кликер для Селениума). И так далее.

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

«Раньше» было проектное управление и годовые планы.

Они никуда не делись :)

есть векторы развития

Ты про булшит-бинго слыхал? :) А про «пишите код блеать»?

В аджайле все команды - кроссфункциональны.

Перевод: универсально сосут во всех вопросах за один мелкий прайс :)

Программист должен уметь и тестировать, и аналитить (но делать это будет хуже), аналитик или администратор - должен чуть хуже тестировать, и совсем плохо программировать (но хоть как-то - должен). И так далее.

ЧТД.

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

хорошо быть тобой. Миллионы баксов зарплату, наверное, получаешь. Ведущие мировые продукты выпускаешь.

Ты за деревьями леса не видишь :)

Команда специалистов лучше команды «недоуниверсалов», особенно если специалисты не боятся быть выкинутыми на мороз за отказ взваливать на себя доп. обязанности без увеличения зп (потому что физически нельзя быть охуенным во всем). Все эти «фулстек» требования за ту же цену — эт разговоры в пользу бедных(стартапы) или жадных(«а чо, так можно было?») Т.е. в микрософте, гугле, твиторе и фейсбуке а) не рокет саенс б) издерки под соусом прогрессивности и прочими песнями «ну ты же комсомолец!» можно лихо сократить :) (и толпы молодняка будут уверены что это правильно и нужно, потому что слаще репы ничо не ели и «все так делают»). Микрософт как бы и раньше уповал на «гуд инаф софтваре» и «эмбрейс-экстенд-экстингуиш» — если ты не застал, то это не значит, что что-то в этом отношении поменялось :)

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

чтобы вся эта толпа на пятьдесят человек из аналитиков, разработчиков, фиг-знает-кого-понанимали, не простаивала - лучше её бросить хоть на что-то, чем они балду будут пинать.

при этом разработчик может хреново выполнить задачи любого человека, поэтому его можно кидать на любой фронт. Ну и пусть, что он делает аналитику в 20 раз хуже профессионального аналитика - бросай на тот фронт 20 бухающих разрабов и всё

точнее, они туда сами пойдут, когда поймут, что перед разработкой скопился затор, и никакая их активность в колонке «разработка» не улучит ситуацию (они не могут эффективно решать 0 задач)

==========

вопрос про то, что разраб хочет заниматься ТОЛЬКО разработкой, решается методами HR. Таких людей не нанимают (или увольняют).

Человеку должно быть интересно и радостно заниматься НАШИМ ОБЩИМ ПРОДУКТОМ в любой роли.

Конечно, у тебя для этого должен быть клёвый продукт.

Так не иди работать в компанию, продукт которой ты не мечтаешь разрабатывать.

Для примера: друг из JetBrains (простой разраб) проверяет багтрекер JetBrains даже распивая с нами в бане спиртные напитки. Просто ему это по кайфу. Читать багтрекер и помогать людям - это его лайфстайл.

папка на рабочем столе, куда скиданы все относящиеся к делу вещи (5-20 документов), и заодно список дел, иногда несколько списков.

Возьми любой нормальный древовидный редактор с возможностью подключения файлов. Типа CherryTree.

Таким образом, если например программер Вася видит, что тестировщик Петя слишком медленно тестирует, он понимает: из-за Пети его зарплата может стать на треть меньше. Или на две трети. И у него возгорается жопа!

а когда забьется сортир, Вася побежит его прочищать? ведь он понимает, что из-за сломанного сортира, Петя слишмо медленно тестирует или вообще домой ушел.

Таким образом, если например программер Вася видит, что тестировщик Петя слишком медленно тестирует, он понимает: из-за Пети его зарплата может стать на треть меньше. Или на две трети. И у него возгорается жопа! И у него есть множество путей - он может попросить другого разраба Диму помочь, и пойти тестировать - каждый из разрабов это полтестировщика, вместе получается 1 тестировщик. Или попробовать взять те задачи, которые еще не отданы на тестирование, и сделать их более просто тестируемыми. Или напимсать для Пети какие-то тулзы, которые ускорят ему тестирование (например, улучшить кликер для Селениума). И так далее.

вариант выставить Петю на мороз и предложить нанять более быстрого тестировщика не рассматривается?

не, это так не работает. Завтра проблемы будут у Васи, и Петя будет у него на подсосе работать недо-программистом, помогая писать юнит-тесты или перебивать апи в XML. Послезавтра проблемы будут у аналитика Маши, и Вася с Петей будут ей рассказывать что заказчик под словом «формат джизон» на самом деле имел ввиду неправильно написанное слово «JSON», а не написание браузерного парсера с помощью Jison (bison for javascript), и на этом можно сэкономить пять дней написания ТЗ.

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

и кстати да, UI, или упаси боже UX тестировщики - не сильно масштабируются вертикально. Нужно тупо увеличивать количество рук, которые будут прокликивать кнопочки, и количество мозгов которые будут смотреть на UI (который только что сделали разрабы) и понимать что UI говно полное

Тред потом перечитаю, сейчас лень. Ну, понеслась.

неудобство хранения всех дел в единой базе.

Это первая ошибка, наверное. Все проходили через эту фазу - я буду заносить туда все вещи, включая «неплохо бы скататься в Монголию покормить лошадок» и «хочу стать космонавтом». Полагаю, что стоит ограничить себя

а) делами, которые точно собираешься делать, а не «хотелками»

б) горизонтом событий месяцев хоть на 6

Иначе это превратится в помойку. Если жалко вытирать, просто заведи себе какой «мусорный» список на харде и скидывай хотелки туда. И не стесняйся список предметов, которые может хочешь купить хранить в вишлисте на амазоне, список книг, которые хочешь прочитать в goodreads а список багов, которые собираешься поправить в текстовом файле прямо в гит-папке проекта. Захламленная система совершенно бесполезна, а для ведения проекта в GTD хватит и очень общей информации.

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

Вторая проблема, с которой сталкивался - не видел удобных программ под ГТД. Те, которые я видел, сделаны по типу однострочных вложенных списков.

Их и нет. Рано или поздно люди начнают все эти системы подгонять под себя. У меня, например, сворованы и подогнаны скрипты, которые позволяют автоматом создавать project-related папки для хранения сопровождающий инфы, а потом когда проект закончен, автоматом их архивировать. В последнее время я по большей части просто создаю на рабочие проекты один файл для scrivener, и храню всю сопровождающую инфу и документы в нем. В общем, не стесняйся экспериментировать.

заметки о нюансах, сложностях, мысли на тему.

Ну это скорее через контексты, наверное. Это самая мутная часть GTD и та, с которой можно поэксперементировать больше всего.

Но вообще, я должен сказать, что GTD и сама по себе, конечно, имеет изрядный оверхед. Особенно тогда, когда события несколько хаотично меняются.