Как стать автором
Обновить

Управление распределенной командой в режиме многопроектности (обзор и видео доклада)

Время на прочтение 12 мин
Количество просмотров 12K
Всего голосов 51: ↑48 и ↓3 +45
Комментарии 17

Комментарии 17

Не нашел у вас на Github-е ни Polk ни Ford))
Всё так, эти инструменты пока не готовы к публичному релизу.
а @channel (событие, оповещающее всех участников канала) и here (событие, оповещающее всех участников канала, находящихся online) использовать только в тех редких и исключительных случаях, когда без них действительно нельзя обойтись


Интересно, как это сочетается с «безадресно и может быть проигнорировано»? Вот наступил редкий исключительный случай и как раз в этом случае сообщение может быть проигнорировано…
тут «тонкий лёд»: может быть проигнорировано тем, кто занимается задачей, но не будет проигнорировано дежурным инженером. А вот прерывание будет создано всем (
Задач в Redmine (нашем трекере задач) слишком много — нужен фокус на тех, что будут в работе именно сегодня. И даже среди них нужно понять, какие задачи сделать в первую очередь, то есть — определить приоритеты. И идеально, если примерно запланировать время, которое мы готовы потратить на каждую задачу…


Неужели нет такой базовой функциональности в Redmine? Или какая-то особенность ее реализации не устраивает?
К сожалению, реализация этого в redmine, по опыту, оказалась крайне неудобной. Изначально именно ею и пользовались.
Вообще-то есть, даже поле “приоритет” есть по умолчанию. А уж заставить исполнителей менять статус задачи на «in progress» — не самая сложная задача.
Да все так, но неудобно релизованы эстимэйты, спенты. И вообще все неудобно. В общем, мы старались сделать так, чтобы инженер максимум отдавал сути задачи, а все, что связано с flow задачи было максимально просто и интуитивно.
Мне кажется, Вам просто хотелось создать свои велосипеды инструменты для управления задачами, slack-бота без объективных на то причин и расчета стоимости создания, внедрения и поддержки данных решений.
Это ощущение появилось у вас от того, что вы увидели картину сейчас. Но инструменты появлялись эволюционно. И в то время мы пробовали жить в просто google docs, redmine, trello, etc… И в итоге пришли к тому, что нужно что-то своё, что будет укладываться в наш flow. Мы продолжаем использовать redmine, но наш redmine уже имеет интеграции с остальными инструментами. Slack-бот — это лишь инструмент для сбора инцидентов в одном месте.
Изобретение велосипедов — вполне понятный и объяснимый этап в жизни любого разработчика и даже менеджера. Сам такой этап прошел, каюсь. Велосипеды имеют право на жизнь, в некоторых ситуациях они вполне оправданы, но текущая ситуация — совершенно не тот случай и я бы сильно рекомендовал обойтись стандартным функционалом с минимальными доделками(веб-хуки и т.д.). Основная причина в этом — то, что велосипеды придется развивать и поддерживать кому-то, править там баги, проводить тесты, то есть это по сути еще одни затраты по деньгами и времени для компании. Впрочем, иногда из таких побочных продуктов вырастают весьма привлекательные стартапы(вспомним тот же Slack). Так же минус в том, что большинство новых сотрудников нужно обучать кастомным вещам — это затраты и время.
велосипеды придется развивать и поддерживать кому-то, править там баги, проводить тесты, то есть это по сути еще одни затраты по деньгами и времени для компании

Спасибо за совет, но я искренне удивлён, если вы думаете, что мы это всё не понимаем :-) Мы не первый год на рынке, да и разработкам этим уже далеко не один год. Так что не просто понимаем, а видим в конкретных цифрах (сколько времени уходит на их развитие и какую пользу они приносят бизнесу). Возможно, у вас просто неполное понимание конкретно нашей картины и/или другой опыт: другие масштабы разработок, компании, ещё что-то другое
Это хорошо, что у Вас есть цифры, если не сложно, сколько стоило создание данных инструментов и их поддержка в год. Думаю, такие цифры будут полезны всем, кто еще только думает создать свои велосипеды инструменты.
Странное у вас представление о бизнесе («расчётах стоимости»), если автор выше уже написал, что изначально мы пользовались тем, что предоставляет тот же Redmine из коробки… а уж за 8+ лет его использования (я даже не поленился проверить дату первого issue в нашей базе) — и не из коробки тоже, поверьте :-))

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

Мы, даже будучи большими любителями Open Source и обладая огромной компетенцией в администрировании, в своё время отказались от разновидностей чатов типа self-hosted в пользу платного(!) Slack. И за много лет ещё не передумали…

TL;DR: если какие-то внутренние разработки появляются — на то есть очень весомые бизнес-причины.
если какие-то внутренние разработки появляются — на то есть очень весомые бизнес-причины.


Дело в том, что я даже прекрасно знаю, какие бывают бизнес-причины и какие последствия от таких решений. Впрочем, каждый волен идти своим путем, раз уже так желает )
Бабах! И production работает нестабильно после пятничного релиза.


Пятничный релиз… А Вы знаете, как разнообразить себе выходные )
Жаль, нельзя поставить сразу 10 плюсов ))))
Зарегистрируйтесь на Хабре , чтобы оставить комментарий