0 просмотренных постов скрыто
Самый опасный проект — тот, в котором все молчат
Иногда тишина в проекте страшнее сотни сообщений.
Помнится один спринт, я тогда еще тимлидил. Рабочий чатик почти пустой. Никаких споров. Никаких вопросов. Никаких «не получается». Созвоны - тихо, спокойно, за 5 минут
Все задачи уверенно стоят в статусе «В работе».
Команда выглядит вполне спокойной. Руководство молчит, видимо радуется в тишине ))
И вот именно тогда мне стало тревожно
Большинство руководителей радуются, когда в рабочем чате тихо.
Я — наоборот. За несколько лет управления разработкой я заметил странную закономерность.
Чем тише проект...
...тем громче обычно заканчивается релиз.
Когда команда работает она действительно шумит
В хорошем проекте постоянно происходит что-то из этого:
— мой дотошный фронт который вечно задает вопросы;
— кто-то спорит с постановкой задачи;
— тестировщик находит странный сценарий;
— разработчик пишет, что API нужно изменить;
— аналитик уточняет требования;
— дизайнер приносит новый макет.
Со стороны кажется, будто проект погружается в хаос.
На самом деле именно так выглядит здоровая работа и проблемы всплывают сразу.
И решаются сразу.
Настоящие проблемы любят тишину
Самые неприятные истории почти всегда начинаются одинаково.
Неделя проходит идеально, да и вторая тоже. Все статусы зелёные и спринт идёт по плану.
А потом...
За два дня до релиза выясняется, что два сервиса используют разные версии API.
Или оказывается, что разработчик неделю писал функциональность по устаревшему ТЗ.
Или тестирование вообще не начиналось, потому что никто не сообщил о блокере.
Никто и ничего не скрывал.
Да просто никто ничего не говорил!
Почему так происходит?
Есть такой интересный психологический эффект.
Когда люди долго не обсуждают проблемы, начинает казаться, что проблем нет. Но разработка работает наоборот. Если сегодня я или еще кто-то не поднял сложный вопрос, это не означает, что его нет.
Потому что чаще всего это означает, что о нём узнают позже.
А позже как известно — всегда дороже.
После таких ситуация я обычно спрашивал разработчика:
— Почему молчал три дня?
Ответ был неожиданно честным.
Думал, сам разберусь.
Не разобрался.
Потеряли почти неделю всей команды.
После этого я перестал считать отсутствие сообщений хорошим признаком. И мой хороший день выглядит иначе.
Утром появляется вопрос а через десять минут начинается обсуждение. Еще через полчаса находится решение.
И уже через час задача снова движется дальше.
Да, сообщений больше. Зато сюрпризов перед релизом гораздо меньше.
Хорошая команда — не самая тихая
Сегодня меня радует не пустой чат.
Меня радует чат, в котором люди не боятся сказать:
«Кажется, здесь проблема.»
Или:
«Не понимаю, объясните.»
Или:
«Мы недооценили задачу.»
Потому что именно после этих сообщений проект становится лучше. Молчание редко экономит время. Обычно оно просто переносит проблему на последний день.
Вместо вывода
В своей команде я смотрю не только на сроки и количество закрытых задач. Мне гораздо интереснее понять, когда команда перестала разговаривать.
Потому что именно после этого обычно начинают сдвигаться сроки, расти технический долг и появляться «неожиданные» проблемы.
И если тишина длится слишком долго — для меня это уже повод открыть проект и разобраться, что происходит на самом деле.
Если вам интересны темы управления разработкой, инженерных процессов и метрик команды — буду делиться подобными наблюдениями регулярно.
Если вам тоже не хватает прозрачности в работе команды, посмотрите демо
Буду рад любой обратной связи — проект еще развивается, и многие идеи появляются именно из таких обсуждений.
Показать полностью
1
Просто работа такая)
Ручной стабилизатор для видеосъёмки DJI Osmo на Али
Мы в Максе https://vk.cc/cZaLoh Мы в Телеге https://t.me/kakvsdelano
Реклама: АЛИБАБА КОМ (РУ) ИНН 7703380158
Алина Антипова
Справедливости ради сама Алина на которой оператор акцентировал внимание 2007 года рождения но в кадре присутствуют другие девушки не достигшие 18 лет поэтому такой тег
Олимпиада на стероидах пройдёт в Лас-Вегасе 24 мая. от России участвует один спортсмен
В Лас-Вегасе готовятся провести соревнования, где спортсменам официально разрешили использовать допинг. Отдел спорта «Фонтанки» — о том, как устроены Enhanced Games, кто оплачивает проект, как в нём оказался петербургский пловец Евгений Сомов и почему критики называют всё это не спортом, а опасным экспериментом.
«Олимпиада на стероидах» (или Enhanced Games) пройдёт 24 мая 2026 года в Лас-Вегасе. Это первые в истории альтернативные спортивные игры, где атлетам не только не запрещено, но и рекомендовано официально использовать медицинские препараты для улучшения результатов.
Главные факты о турнире:
Даты и место: 24 мая 2026 года, комплекс Resorts World в Лас-Вегасе (США).
Формат: Соревнования проходят без антидопингового контроля под наблюдением врачей, цель мероприятия — показать возможности биохакинга.
Отдельного упоминания заслуживает заявленный призовой фонд. Победитель каждой дисциплины получает 250 тыс. долларов; за установление нового мирового рекорда полагается бонус в размере 1 млн долларов. Одним из тех, кто сразится за эту гору денег, оказался и уроженец Петербурга.
Единственным российским участником «Игр на стероидах» стал петербургский пловец Евгений Сомов — мастер спорта международного класса, специализируется на брассе. Юниором он выигрывал чемпионаты Европы и мира, в 2019‑м уехал учиться в США, где выступал за университет Луисвилла и становился призёром NCAA. В сезоне‑2024 Сомов триумфально вернулся: на турнире в Атланте проплыл 100 метров брассом за 58,72 секунды, став первым россиянином, выплывшим из минуты на этой дистанции. На Олимпиаде в Париже он был единственным пловцом с российским паспортом — выступал под нейтральным флагом, прошёл в полуфинал, но медалей не взял.
После Игр Сомов оказался в подвешенном состоянии: возвращаться в Россию он не собирался, а нейтральный статус на тот момент не гарантировал участия в крупных стартах. В декабре 2025‑го организаторы Enhanced Games объявили о подписании с ним контракта. Сам спортсмен отреагировал на это ироничным постом: «На пике своей чистоты». Позже в интервью он объяснил свое решение тем, что ему «интересно делать разные вещи».
Следить за ходом турнира и изучить его концепцию можно на официальном сайте Enhanced Games
Формат и дисциплины: три арены — один стадион
Программа первых Игр сознательно сужена до трёх видов:
Плавание. В программу вошли короткие дистанции: 50 и 100 метров вольным стилем, а также 50 и 100 метров баттерфляем и брассом. Именно в плавании Enhanced Games удалось провести свой главный рекламный эпизод. В 2025 году далеко не самый выдающийся спринтер Кристиан Гколомеев в запрещённом сейчас полиуретановом костюме и после курса препаратов на показательном заплыве в Северной Каролине проплыл 50 метров вольным стилем за 20,89 секунды. Это на две сотые быстрее официального мирового рекорда. World Aquatics результат, конечно, не признала, но организаторы проекта выписали пловцу чек на 1 млн долларов.
Спринт. Мужские и женские забеги на 60 и 100 метров. Среди подтверждённых участников — чемпион мира Фред Керли (США), серебряный призёр чемпионата мира Марвин Брэйси-Уильямс (США), британский спринтер Рис Прескод, а также представители Ямайки, Гайаны, Либерии и других стран.
Тяжёлая атлетика. На помост выйдут призёры Олимпийских игр и чемпионатов мира: канадец Боуди Сантави, нигерийка Марьям Усман (бронза Пекина-2008, чемпионка Игр Содружества), колумбийцы Йони Андика, Арлей Мендес, Лейди Солис и Хуан Солис, а также исландский стронгмен Хафтор Бьёрнссон — Гора из «Игры престолов».
Всего, по данным организаторов, заявлено около 50 участников
список где смотреть на официальном сайте -
Показать полностью
Как я в одиночку запустил SaaS-трекер задач: про поиск пользователей, перенос серверов в РФ и реальность соло-разработки
Когда читаешь истории стартапов, создаётся впечатление, что главная сложность — написать сам продукт. Кажется, что если идея хорошая и код работает, дальше всё пойдёт по накатанной: пользователи придут сами, инфраструктура будет масштабироваться по мере роста, а команда постепенно появится вокруг проекта.
На практике всё выглядит совсем иначе.
Последний год я занимался разработкой собственного SaaS-сервиса — Pabit, инструмента для управления проектами и задачами. В нём есть задачи, спринты, модули проектов, аналитика и несколько других вещей, которые помогают командам структурировать работу над продуктом. И хотя саму разработку я тоже не назвал бы лёгкой, неожиданно оказалось, что основная сложность вообще не в коде.
В этой статье я хочу рассказать о трёх вещах, которые оказались самыми непростыми: поиск первых пользователей, перенос инфраструктуры на российские серверы и работа над продуктом в одиночку, без команды и внешней поддержки.
Когда продукт готов, начинается самое сложное
На ранних этапах разработки кажется, что главное — довести систему до состояния, когда ей можно пользоваться. У тебя есть список функций, архитектура, задачи в бэклоге, и всё это постепенно превращается в работающий сервис.
Но в какой-то момент продукт становится достаточно стабильным, чтобы его могли использовать другие люди. И именно в этот момент приходит понимание: наличие работающего продукта вовсе не означает, что кто-то о нём узнает.
Рынок инструментов для управления проектами давно сформирован. Существуют крупные решения, которые используют тысячи компаний по всему миру: например, Jira, Trello или Asana. У каждого из них огромная пользовательская база, развитая экосистема и многолетняя история.
На фоне таких продуктов новый сервис практически незаметен. Даже если он решает реальные проблемы и обладает удобным интерфейсом, люди просто не знают о его существовании.
В результате поиск первых пользователей превращается в отдельную, довольно сложную задачу. Приходится писать статьи, публиковаться в профессиональных сообществах, записывать короткие демонстрации продукта и отвечать на десятки вопросов о том, чем именно твой инструмент отличается от других.
Особенно непросто это делать, когда ты одновременно остаёшься и разработчиком, и человеком, который пытается рассказать миру о своём проекте.
Инфраструктура — это всегда немного боль
Вторая неожиданная сложность появилась тогда, когда проект уже работал и начал постепенно обрастать первыми пользователями.
Изначально инфраструктура сервиса была развёрнута на зарубежных площадках — это стандартный выбор для многих стартапов. У таких провайдеров удобные инструменты, развитая экосистема и понятная документация, а запуск новых сервисов обычно занимает считанные минуты.
Однако со временем возникла необходимость перенести инфраструктуру на серверы, расположенные на территории России. Причины для этого довольно прагматичные: некоторые компании предъявляют требования к размещению данных, а кроме того, важно было обеспечить стабильный доступ к сервису без зависимости от внешних факторов.
На бумаге переезд инфраструктуры выглядит довольно просто: нужно поднять новые серверы и перенести данные. На практике это превращается в полноценный инфраструктурный проект.
Приходится аккуратно переносить базы данных, проверять совместимость окружений, перенастраивать сетевую архитектуру и тестировать производительность. Любая ошибка на этом этапе может привести к проблемам с доступностью сервиса или потерей данных, поэтому процесс требует аккуратности и большого количества тестов.
Особенно интересно заниматься такими вещами, когда в проекте нет отдельного DevOps-инженера и все задачи по инфраструктуре решает тот же человек, который пишет код.
Соло-разработка: когда ты и команда, и поддержка
Работа над продуктом в одиночку — это довольно необычный опыт. В больших компаниях за разные части системы отвечают разные специалисты: кто-то занимается backend-разработкой, кто-то проектирует интерфейсы, кто-то настраивает инфраструктуру и следит за стабильностью работы сервиса.
В соло-проекте все эти роли объединяются в одном человеке.
В течение одного дня можно успеть исправить несколько багов в backend-части, обновить пользовательский интерфейс, заняться настройкой серверов и ответить на письма пользователей. Иногда приходится переключаться между совершенно разными задачами буквально каждые несколько часов.
С одной стороны, такой формат даёт большую свободу: решения принимаются быстро, а архитектура проекта полностью зависит от твоего собственного видения. С другой стороны, отсутствие команды означает, что любой сложный вопрос приходится решать самостоятельно.
Почему вообще появился Pabit
Идея проекта появилась из довольно простой практической проблемы. Работая над различными проектами, я постоянно сталкивался с тем, что большинство существующих таск-трекеров находятся на одной из двух крайностей.
Одни системы оказываются слишком простыми и предлагают лишь базовую канбан-доску с карточками задач. Другие, наоборот, обладают огромным количеством настроек и функций, из-за чего работа с ними превращается в отдельный процесс, требующий времени и внимания.
Хотелось создать инструмент, который находился бы где-то посередине. Такой сервис должен позволять структурировать задачи, планировать спринты и анализировать прогресс команды, но при этом не перегружать пользователя сложными конфигурациями и десятками экранов настроек.
Так постепенно появился Pabit — инструмент для управления проектами, который помогает отслеживать задачи, запускать спринты и работать с продуктовой структурой проекта через модули и аналитические панели.
Что есть в сервисе сейчас
На текущий момент в системе реализован базовый набор инструментов, который позволяет командам управлять разработкой продукта. Пользователи могут создавать задачи и подзадачи, планировать работу в рамках спринтов, разбивать проект на модули и отслеживать прогресс через аналитические панели.
Кроме того, в системе есть страницы для идей и заметок, которые можно превращать в задачи по мере необходимости. Такой подход позволяет не терять мысли и постепенно превращать их в конкретные действия внутри проекта.
Основная цель сервиса — дать команде понятную и прозрачную картину того, что происходит в проекте, не перегружая интерфейс лишними элементами.
Что дальше
Любой SaaS-проект — это долгий процесс. Даже после запуска остаётся огромное количество задач: нужно улучшать интерфейс, добавлять новые функции, оптимизировать производительность и продолжать работать над инфраструктурой.
Но, пожалуй, самая важная часть — это обратная связь от пользователей. Именно она помогает понять, какие вещи действительно полезны, а какие идеи лучше оставить в бэклоге.
Если вам интересно посмотреть, как выглядит сервис и что уже реализовано, можно заглянуть на сайт проекта:
https://pabit.ru
Буду рад любому фидбеку, особенно от людей, которые уже работали с системами управления проектами и могут сравнить разные подходы к организации задач и процессов.
Показать полностью
3