Комментарии 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: если какие-то внутренние разработки появляются — на то есть очень весомые бизнес-причины.
У нас предостаточно более целевой (= приносящей прямые деньги) работы, чем разработка внутренних сервисов.
Мы, даже будучи большими любителями Open Source и обладая огромной компетенцией в администрировании, в своё время отказались от разновидностей чатов типа self-hosted в пользу платного(!) Slack. И за много лет ещё не передумали…
TL;DR: если какие-то внутренние разработки появляются — на то есть очень весомые бизнес-причины.
Бабах! И production работает нестабильно после пятничного релиза.
Пятничный релиз… А Вы знаете, как разнообразить себе выходные )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление распределенной командой в режиме многопроектности (обзор и видео доклада)