Сначала я хотел сделать таск-трекер. Потом случайно начал строить целую операционную систему для команд
Я не планировал создавать ещё один таск-трекер. Когда я впервые начал думать над Pabit, у меня не было идеи построить большую платформу для управления командами, которая должна была бы конкурировать со всеми существующими сервисами одновременно. Наоборот, изначальная задумка была довольно приземлённой: мне просто хотелось сделать инструмент, которым было бы удобно пользоваться российским командам.
Потому что с существующими сервисами постоянно возникали какие-то компромиссы.
Вроде бы всё необходимое уже есть: задачи, статусы, проекты, комментарии, отчёты. Но когда начинаешь использовать такие системы в реальной работе, довольно быстро выясняется, что универсальность иногда работает против тебя. Инструмент может быть очень мощным, но при этом совершенно не учитывать то, как конкретно привыкли работать люди и команды.
Особенно это заметно, когда ты пытаешься организовать работу не в абстрактной «команде из учебника», а в обычной российской компании, где одновременно могут использоваться Telegram, несколько таблиц, таск-трекер, документы, почта и ещё какой-нибудь сервис, который выбрали пять лет назад, потому что тогда он казался хорошей идеей.
В итоге получается довольно интересная конструкция. Задачи находятся в одном месте, документация — в другом, обсуждение происходит в Telegram, файлы лежат где-то ещё, а важное решение, принятое на созвоне две недели назад, вообще существует только в голове у одного человека.
И пока этот человек помнит, что именно было решено, система вроде бы работает.
А потом он уходит в отпуск.
Сначала всё было очень просто
Я хотел сделать нормальный таск-трекер.
Именно нормальный, а не «давайте добавим ещё 47 настроек, чтобы каждый пользователь мог настроить абсолютно всё».
Создал задачу, написал, что нужно сделать, назначил исполнителя, поставил срок, посмотрел статус. Казалось, что на этом можно остановиться и спокойно жить дальше.
Но довольно быстро появилась первая проблема: задача сама по себе почти никогда не содержит всей необходимой информации.
Например, можно написать:
«Добавить оплату картой».
И формально это задача.
Но что именно нужно сделать? Для какого продукта? Какие ограничения есть у платёжной системы? Как должен выглядеть пользовательский сценарий? Какие решения уже принимались? Есть ли макеты? Кто обсуждал эту задачу с заказчиком? Что делать, если платёж не прошёл?
Всё это обычно находится где угодно, только не рядом с самой задачей.
И в этот момент я начал понимать, что хороший таск-трекер должен каким-то образом работать не только с задачами, но и с контекстом вокруг них.
А контекст — это уже документация.
Так появились страницы
Сначала я подумал, что можно просто добавить возможность создавать страницы и хранить там дополнительную информацию.
Вроде бы логично: есть задача, рядом есть описание проекта, рядом есть документация.
Но потом возникает следующий вопрос: а как связать всё это между собой?
Потому что если у тебя есть отдельно задачи и отдельно страницы, то через некоторое время ты снова получаешь два разных мира, между которыми нужно постоянно прыгать.
Тогда появились связи, структура, разные представления, возможность организовывать информацию внутри проекта.
И в какой-то момент я поймал себя на мысли, что первоначальный таск-трекер начинает превращаться во что-то гораздо большее.
Причём это происходило не потому, что я однажды сел и решил: «Сегодня я построю операционную систему для команд».
Наоборот, каждая новая функция казалась вполне логичной сама по себе.
Нужны задачи — добавляем задачи.
Нужен контекст — добавляем страницы.
Нужно планировать крупную работу — добавляем модули и циклы.
Нужно видеть проект в другом формате — добавляем представления.
Нужно понимать, что происходит в целом, — добавляем аналитику.
А потом ты смотришь на проект и понимаешь, что теперь это уже точно не просто таск-трекер.
В какой-то момент я понял, что проблема вообще не в задачах
Большинство команд не испытывает проблем с тем, чтобы создать задачу.
С этим всё обычно довольно просто.
Проблема начинается позже, когда нужно понять, что происходит с этой задачей через неделю, через месяц или через полгода.
Почему она появилась? Какую проблему решает? Кто ещё от неё зависит? Что обсуждалось до начала работы? Почему приняли именно такое решение?
В маленькой команде часть этой информации хранится в голове у людей, потому что все и так постоянно общаются друг с другом.
Но по мере роста команды этот подход начинает ломаться. Люди начинают забывать, где именно что обсуждалось, новые сотрудники не понимают, почему проект устроен именно так, а руководителю приходится регулярно собирать информацию вручную.
В результате команда вроде бы работает, но значительная часть времени уходит не на саму работу, а на попытки восстановить контекст.
«А почему мы вообще это делаем?»
«Кто это сейчас ведёт?»
«А где описание?»
«Это уже согласовали или только обсуждали?»
«А что было решено на прошлом созвоне?»
Если вы работали в команде, то, скорее всего, хотя бы несколько таких вопросов вам знакомы.
Pabit появился именно из этой проблемы
Мне хотелось сделать систему, в которой работа команды не была бы разложена по пяти или десяти разным сервисам.
Не в смысле «давайте заменим абсолютно всё одним огромным комбайном», потому что такие попытки обычно заканчиваются интерфейсом, в котором уже никто не понимает, куда нажимать.
Скорее хотелось собрать рядом те вещи, которые действительно связаны между собой.
Задача должна иметь контекст.
Проект должен иметь структуру.
Документация должна быть связана с работой, которую команда выполняет.
Планирование не должно существовать отдельно от реального прогресса.
А руководитель должен иметь возможность открыть систему и понять, что происходит, не отправляя пять сообщений в разные чаты.
Именно поэтому Pabit постепенно начал превращаться в нечто большее, чем обычный таск-трекер.
Самая большая ошибка — думать, что продукт это просто код
Как разработчику, мне сначала казалось, что самая сложная часть будет технической.
Нужно продумать архитектуру, написать код, сделать интерфейс, решить вопросы с базой данных, разобраться с производительностью, исправить баги и не сломать всё очередным изменением.
И да, технических проблем хватает.
Но со временем я понял, что написать функцию зачастую проще, чем понять, нужна ли она вообще.
Можно потратить несколько дней или даже недель на реализацию идеи, которая кажется очень полезной, а потом показать её пользователю и получить вполне закономерный вопрос:
«А зачем это?»
И это, наверное, один из самых неприятных, но одновременно самых полезных моментов в разработке продукта.
Потому что постепенно начинаешь понимать: продукт — это не количество функций, которые удалось реализовать.
Можно сделать огромную систему, в которой будет всё, что только можно придумать, но пользователю всё равно будет неудобно решать свою конкретную задачу.
Поэтому сейчас я стараюсь смотреть на Pabit не как на набор возможностей, а как на рабочий процесс.
Человек приходит в систему не для того, чтобы посмотреть на красивый список функций. Он приходит, потому что ему нужно понять, что делать, зачем это делать, кто этим занимается и какой результат должен получиться.
Если система помогает ответить на эти вопросы, значит, она приносит пользу.
Если нет — наличие ещё одной функции ситуацию не спасёт.
Почему именно российские команды
Я не считаю, что российским командам нужен какой-то совершенно отдельный тип программного обеспечения.
Мы не работаем каким-то магическим образом, который полностью отличается от всего остального мира.
Но при этом у нас есть свои привычки, свои процессы и свой опыт использования различных инструментов.
Многие команды уже привыкли работать в определённой связке сервисов, многие сталкивались с ограничениями зарубежных продуктов, а многие просто хотят использовать продукт, который развивается с пониманием местного рынка, а не является очередным переводом существующего решения.
Мне хотелось попробовать сделать именно такой продукт.
Не копировать один в один Jira, Notion или Linear, потому что в этом случае возникает закономерный вопрос: зачем вообще нужен ещё один такой же сервис?
А попытаться собрать собственное понимание того, каким должен быть инструмент для команды.
Пока это получается не всегда идеально, и я прекрасно понимаю, что Pabit ещё очень далеко от того продукта, которым я хочу его видеть.
Но, наверное, любой продукт именно так и развивается: сначала у тебя есть идея, потом появляется первая версия, затем пользователи начинают показывать, где ты ошибся, и постепенно первоначальная идея начинает сильно отличаться от того, что ты собирался делать в самом начале.
И вот что получилось в итоге
Я начинал с мысли, что хочу сделать удобный таск-трекер.
Потом понял, что задачам нужен контекст.
Контекст потребовал документации.
Документация потребовала структуры.
Структура потребовала планирования.
Планирование потребовало аналитики.
А всё вместе постепенно начало превращаться в полноценное рабочее пространство для команды.
И теперь, когда я смотрю на Pabit, мне уже сложно назвать его просто таск-трекером.
Скорее это попытка создать единое место, где команда может планировать работу, хранить контекст, управлять задачами и понимать, что происходит с проектом в целом.
И, возможно, именно в этом и заключается самая большая ирония всей истории.
Я не собирался строить большую систему для команд.
Я просто хотел сделать хороший таск-трекер.
Но, как это часто бывает с разработкой собственных продуктов, в какой-то момент оказалось, что ты уже слишком далеко зашёл, чтобы остановиться.
Поэтому Pabit продолжает развиваться.
Я продолжаю добавлять новые возможности, переделывать старые, удалять то, что оказалось не таким полезным, как казалось вначале, и пытаться понять, каким должен быть инструмент, которым команда действительно захочет пользоваться каждый день.
Если вы работаете над проектами, управляете командой или просто устали искать информацию по пяти разным сервисам, можете попробовать Pabit и рассказать, чего в нём не хватает.
Мне особенно интересна обратная связь от людей, которые реально работают в командах, потому что именно из таких разговоров обычно и появляются самые полезные изменения.
А я пока продолжу делать то, с чего всё началось.
Пытаться создать хороший таск-трекер.
Правда, теперь почему-то вместе с документацией, планированием, аналитикой и всем остальным.
Похоже, остановиться уже действительно поздно.
А с сайтом проекта и тем, что я намудрил, можно ознакомиться тут https://pabit.ru/
