Написал им в саппорт, ответили на следующий день и великодушно открыли доступ на 48ч. Далее успешно экспортировал в json все доски и перс.данные (на всякий случай).
У нас нет выделенной роли архитектора во всем Озонтехе. CTO принципиально против.
Что касается архитектуры, такие решения принимаются либо на местах, по договоренности, либо эскалируются выше. При разногласиях, финальное решение принимает наименьший общий руководитель, который всегда в какой-то степени считается архитектором.
А вот к какому домену отнести - это немного другое. Это уровень бизнес-логики, из которой и следует архитектура. Тут мы исходим из логики деления на домены (предметные области). Обычно легко удаётся договориться, поскольку границы доменов очерчены. Если же не удаётся - обычно это означает, что "демаркация" не доделана до конца. Вот тут включается более сложный процесс, в котором принимают участие все, кого затрагивает передел границ.
Расшевелить команду, если катастрофически нет времени или другие подходы по каким-то причинам не удаётся применить. Но это только про "налететь и пошуметь". Беспорядок после себя оставлять больше того, который уже был, конечно нельзя, иначе это не решение проблемы, а её усугубление. В силу разных причин бывают команды, где иногда без шума что-либо плохо движется. А некоторые воспринимают отсутствие шума как отсутствие у менеджера интереса к задаче.
Но, чтобы применять такое, надо иметь достаточный опыт и понимание, когда такой трюк имеет смысл делать. И это разовая акция краткосрочного действия.
В общем, применимость весьма небольшая и частичная.
Возможно такой приём как-то ещё называется, но и чайки чаще шумят, чем гадят )
Я бы сказал, что чайка-менеджмент как приём в управлении иногда может быть полезным, если применять прицельно и умеренно. Но если это превратилось в стиль управления - тогда проблема.
Простейший рабочий лайфхак для сохранения здоровья и продуктивности - минимизировать время перед монитором любыми способами и больше двигаться :) IT-трудягам платят за решение конкретных прикладных задач, где надо думать, а не просто за артефакты в виде строчек кода или диаграмм. А думать не обязательно сидя перед монитором.
Например, если надо поразмыслить - можно встать с кресла и походить по комнате, набросать план на бумажке. Участвовать в созвоне можно стоя , а не сидя, и заодно отдохнуть от монитора, смотря на него изредка. Много чего можно придумать, тут все средства хороши.
Бытует мнение, что ретроспектива это скучная встреча без явной пользы.
Кажется, всё ровно наоборот: ретро, наверное, самый важный и мощный из всем известных командных ритуалов. Это долгосрочная инвестиция в продуктивность команды. Без поиска узких мест и постоянных улучшений, сложно добиться успеха.
Как было правильно написано, очень важна подготовка, а особенно - понимание, какие проблемы нужно решить в команде. А также выполнимый план по конкретным улучшениям на выходе и готовность его претворить в жизнь.
На у техники проведения ... это хорошо, что их много: можно выбрать те, которые выстрелят в конкретной команде. Пару новых почерпнул, спасибо.
В нашем случае, координатор напрямую с инженерами не общается, хотя бы вследствие масштаба, т.к. инженеров на таких проектах не один десяток.
А вот тимлид инженера или продакт его домена - вполне может продавить костыли.
Гляньте выше, описал подробно.
Написал им в саппорт, ответили на следующий день и великодушно открыли доступ на 48ч. Далее успешно экспортировал в json все доски и перс.данные (на всякий случай).
Вот по этой ссылке форма https://trello.com/en/contact#/
Нужно промотать вниз, нажать Continue without logging in и заполнить форму.
Через Mozilla почему-то не сработало, через Chrome все получилось.
Тоже блокировка личного аккаунта оказалась неожиданностью.
Через web/мобильное приложение никак не предупреждали. Почту, на которую аккаунт зареган, читал редко, письмо не заметил.
Восстановить данные/сделать экспорт из этого самого trello теперь совсем никак?
Самобытное :)
Умолчал потому, что тянет на отдельную статью. В этой и так букв хватает.
У нас нет выделенной роли архитектора во всем Озонтехе. CTO принципиально против.
Что касается архитектуры, такие решения принимаются либо на местах, по договоренности, либо эскалируются выше. При разногласиях, финальное решение принимает наименьший общий руководитель, который всегда в какой-то степени считается архитектором.
А вот к какому домену отнести - это немного другое. Это уровень бизнес-логики, из которой и следует архитектура. Тут мы исходим из логики деления на домены (предметные области). Обычно легко удаётся договориться, поскольку границы доменов очерчены. Если же не удаётся - обычно это означает, что "демаркация" не доделана до конца. Вот тут включается более сложный процесс, в котором принимают участие все, кого затрагивает передел границ.
Это в любом случае нужно делать (и не только это), иначе не выйти из замкнутого круга, и чайка-менеджмент превратится в стиль.
Расшевелить команду, если катастрофически нет времени или другие подходы по каким-то причинам не удаётся применить. Но это только про "налететь и пошуметь". Беспорядок после себя оставлять больше того, который уже был, конечно нельзя, иначе это не решение проблемы, а её усугубление. В силу разных причин бывают команды, где иногда без шума что-либо плохо движется. А некоторые воспринимают отсутствие шума как отсутствие у менеджера интереса к задаче.
Но, чтобы применять такое, надо иметь достаточный опыт и понимание, когда такой трюк имеет смысл делать. И это разовая акция краткосрочного действия.
В общем, применимость весьма небольшая и частичная.
Возможно такой приём как-то ещё называется, но и чайки чаще шумят, чем гадят )
А приоритет этого проекта был какой? Может команда ещё пяток проектов делала параллельно?
Я бы сказал, что чайка-менеджмент как приём в управлении иногда может быть полезным, если применять прицельно и умеренно. Но если это превратилось в стиль управления - тогда проблема.
Для крупной компании пункт выглядит малореальным - такие даже испытательный срок не пройдут, либо быстро научатся пользоваться.
А вот пункт "Не умеют назначать встречи" очень распространен среди новичков. Например:
Приглашают не всех, кого нужно или наоборот, лишних
Встреча без повестки, а ещё лучше - с непонятным названием и с непонятной целью
Назначают внезапно, а не заранее
У нас 100% внутренняя разработка, и я готов подписаться под всеми шестью пунктами.
По крайней мере, для крупной компании это очень даже актуально.
А что насчет аренды жилья? Цены и насколько легко найти хороший вариант.
Спасибо, весьма познавательно!
Особенно порадовал радикальный трюк в ускорении натурализации: жениться на местной :)
А то часто пишут про проблемы с общением после переезда.
Простейший рабочий лайфхак для сохранения здоровья и продуктивности - минимизировать время перед монитором любыми способами и больше двигаться :) IT-трудягам платят за решение конкретных прикладных задач, где надо думать, а не просто за артефакты в виде строчек кода или диаграмм. А думать не обязательно сидя перед монитором.
Например, если надо поразмыслить - можно встать с кресла и походить по комнате, набросать план на бумажке. Участвовать в созвоне можно стоя , а не сидя, и заодно отдохнуть от монитора, смотря на него изредка. Много чего можно придумать, тут все средства хороши.
Кажется, всё ровно наоборот: ретро, наверное, самый важный и мощный из всем известных командных ритуалов. Это долгосрочная инвестиция в продуктивность команды. Без поиска узких мест и постоянных улучшений, сложно добиться успеха.
Как было правильно написано, очень важна подготовка, а особенно - понимание, какие проблемы нужно решить в команде. А также выполнимый план по конкретным улучшениям на выходе и готовность его претворить в жизнь.
На у техники проведения ... это хорошо, что их много: можно выбрать те, которые выстрелят в конкретной команде. Пару новых почерпнул, спасибо.