Как правильно делегировать задачи, когда никто не хочет брать ответственность?

Предыдущая публикация Следующая публикация

Похожие новости

Кто-нибудь знает про успешные стартапы в Томске? Очень надо! — бизнес развитие
Привет всем! Пытаюсь найти вдохновение и понять, какие бизнесы в Томске реально выстрелили. Смотрел на всякие общие рейтинги, но хочется чего-то местного,
Основы бизнеса: что реально важно для стартапера?
Мне кажется, многие новички в стартапах зацикливаются на каких-то мелочах, типа идеального логотипа или модного офиса. Хотя, возможно, я ошибаюсь. Имхо, куда
Основы бизнеса для новичка: Забудьте про теории, давайте к делу!
Ребят, тут часто спрашивают про основы бизнеса, всякие там «что такое бизнес-план» и «как найти свою нишу». Имхо, вся эта академическая фигня часто отпугивает.
Как брендинг стартапа в Томске может выделиться?
Ребят, тема такая. Есть стартап, вроде бы и ниша интересная, и продукт неплохой. Но вот с брендингом беда. Как сделать так, чтобы нас заметили среди прочих? Мы
Партнерство: где найти надежных партнеров для стартапа в Томске?
Народ, реально нужна помощь! У меня есть идея, прототип, но не хватает одного ключевого человека в команду, который бы закрыл техническую часть. Где в Томске
Информация
Посетители, находящиеся в группе Гости Kraken, не могут оставлять комментарии к данной публикации.

Комментариев 6

DigitalTomsk
0
DigitalTomsk Офлайн 8 марта 2026 08:31

Привет, CreativeMind! Знакомая ситуация, да.

У меня на одном из прошлых проектов была похожая петрушка. Стартап в сфере онлайн-образования, команда тоже небольшая. Помнится, надо было оперативно допилить новый модуль для платформы. Я, как тимлид, выделил конкретные подзадачи: разработка фронтенда, бэкенд, тестирование. И вот тут началось...

  • Фронтендер отдал код, но заявил, что «это максимум, что я смог выжать из текущих ресурсов».
  • Бэкендер сказал, что «без готового фронта он не может проверить интеграцию».
  • Тестировщик вообще сказал, что «не может приступить, пока обе части не будут готовы и не будет документации»

Короче, я тогда понял, что просто раздать задачи — это полдела. Важно еще, чтобы люди чувствовали себя частью процесса, а не просто исполнителями. В итоге пришлось провести небольшой спринт-планирование, где мы вместе с командой определили зависимости, риски и, главное, распределили ответственность за каждый этап, включая «выявление и решение проблем». И как-то сразу дело пошло бодрее. Ну, и мотивацию подтянул, конечно, привязал премии к достижению KPI по модулю. Результат — модуль сдали в срок, и даже с запасом.

Жалоба
StartupDreamer
0
StartupDreamer Офлайн 8 марта 2026 21:35

DigitalTomsk, да, понимаю о чем ты. У меня похожая фигня была. Ну, короче, когда команда не берет ответственность, это часто проблема не в людях, а в системе.

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

И еще, когда проблема возникает, не решай ее за них сразу. Попроси их самих предложить варианты решения. Можно даже устроить мозговой штурм, где каждый должен высказать хотя бы одну идею. Это заставит их думать, а не просто ждать указаний.

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

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

--------------------

Удачи всем :) — StartupDreamer

Жалоба
HumorBiz
0
HumorBiz Офлайн 8 марта 2026 18:01

Ох уж эти "ответственные" сотрудники, ахах! Ну это классика жанра, когда от тебя ждут, что ты будешь с бубном танцевать, чтобы кто-то хотя бы взглянул на задачу. StartupDreamer, ты прав, дело часто в системе. Но давай добавим перчинки!

Кстати, а вы пробовали метод "обратной ответственности"? Вместо того чтобы говорить "ты отвечаешь за это", скажите: "Если этот проект провалится, то кто, по-твоему, должен взять на себя вину?" Ну, типа, посмотреть на их реакцию. Или еще вариант: ввести "кодекс стартапера", где будет прописано, что каждый член команды — это не просто винтик, а часть большого и ужасно веселого механизма, который должен работать, даже если он скрипит и разваливается на ходу. Шутки шутками, но иногда жесткие, но понятные правила лучше, чем недосказанность.

А еще, представь, что вы выпускаете новую фичу. И вместо того, чтобы просто раздать задачи, устройте "боевое крещение" для каждого. Пусть каждый представит свою часть работы не просто как "сделал", а как "вот, я это родил, и теперь оно будет жить своей жизнью, а если что, я его спасу!". Такая игра в "родителей" проекта может очень мотивировать. Ну, или просто посмеяться над тем, как все пошло не так. Зато весело)

--------------------

мнение может отличаться от здравого смысла ))

Жалоба
InvestigatorTomsk
5
InvestigatorTomsk Офлайн 8 марта 2026 14:07

StartupDreamer, про зоны ответственности — это интересно. Звучит разумно

Но вот что смущает: разве это не тот же самый "делегирующий" подход, только под другим соусом? Мне кажется, проблема глубже.

Если люди изначально не хотят брать на себя ответственность, то простое переименование "задачи" в "зону ответственности" ситуацию не изменит. Они просто скажут: "Это твоя зона ответственности, а я просто исполнитель".

Откуда инфа, что это сработает? Может, стоит попробовать другой подход? Например, систему поощрений за инициативу или, наоборот, более четкие последствия за уклонение от проблем.

Ну, или хотя бы понять, почему они этого избегают. Не хотят? Не умеют? Боятся?

--------------------

— InvestigatorTomsk

Жалоба
ActiveStarter
0
ActiveStarter Офлайн 8 марта 2026 13:14

StartupDreamer, вот точно! Ты прям в точку попал про зоны ответственности. Я сам недавно об этом думал

У меня в похожей ситуации с клиентом был момент. Мы делали мобильное приложение, и один разработчик постоянно сливался когда дело касалось тестирования. Я ему просто давал задачу "протестируй экран такой-то". Ну и что, он типа запускал пару раз и все. А потом я переформулировал: "Ты отвечаешь за бесперебойную работу экрана авторизации". И всё, он уже сам додумывал, как это лучше сделать, какие тесты провести. Результат, конечно, небо и земля. Так что, кмк, это реально работает. Главное — четко обозначить, за что человек реально рулит, а не просто что делает

Жалоба
TomskInvest
0
TomskInvest Офлайн 8 марта 2026 17:04

Ну, CreativeMind, тут история, которая разворачивается, как будто ты описываешь стандартный сценарий для молодого стартапа. Интересно, что никто еще не затронул аспект формирования культуры ответственности с самого начала. Часто ведь как бывает: если основатель сам "тушит пожары" и принимает на себя всю критику, команда неосознанно привыкает, что это его прерогатива, а не их общая задача.

Практика показывает, что делегирование — это не просто выдача инструкций. Это еще и предоставление полномочий для принятия решений в рамках своей зоны. Когда человек получает задачу, но не имеет права самостоятельно выбрать инструмент или метод её решения, он остается лишь исполнителем, а не ответственным. И тут, DigitalTomsk, твоя аналогия с разработкой модуля становится особенно актуальной: важен не только сам модуль, но и то, кто и как его будет дорабатывать.

StartupDreamer, ты правильно подметил про зоны ответственности. Я бы добавил, что стоит четко проговаривать ожидаемый результат и критерии успеха для каждой такой зоны. Чтобы у каждого было ясное понимание, к чему стремиться, а не просто "сделать Х".

HumorBiz, метод "обратной ответственности" — это, конечно, пикантно. Но, кмк, иногда нужно начинать с более фундаментальных вещей. Может, стоит внедрить регулярные "ретроспективы", где команда сама будет обсуждать, что получилось, а что нет, и почему. Это тоже способствует вовлечению и осознанию своей роли.

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

Жалоба