А что происходит с отловленными ошибками дальше? Загорается какая-то лампочка в админке, и какие-то дежурные разбираются в ситуации?
И что будет, если в релизе выкатится фатальная ошибка какой-нибудь жутко популярной ручки, не заддосит ли ваш механизм сбора ошибок?
У нас небольшие команды, 3-4 человека, просто договариваемся когда все в сети. Не каждый день конечно, но 2-3 раза в неделю достаточно.
Кажется, это ключевое. Действительно, если проектная команда небольшая, то договориться легко. А если ресурсов требуется больше, то никто не мешает разбить команду на подкоманды и договариваться локально. Пересечения у графиков найти можно всегда.
За последние несколько месяцев наняли 6 разработчиков и 2 тестировщиков, нескольких менеджеров (это именно в нашу команду). И никому не пришлось ни ломать график, ни жертвовать своим временем.
То есть примеры Ваши в отрыве от контекста звучат здраво, но на практике как минимум конкретно в моем случае не воспроизводятся.
Просто нужно мотивировать дизайнера передавать все материалы.
Вообще более чем за год подобной работы не сталкивался с описанными вами проблемами, кажется, если они потенциально возможны — значит, либо какие-то люди не подходят для работы в распределенной команде со свободным графиком, либо проблемы с мотивацией персонала.
Но есть проблема не в подходе в целом, а в конкретной его реализации.
Курс — огонь! Интереснее сериалов :)
Спасибище за перевод, смогу попробовать мотивировать смотреть тех, кто отказывался от просмотра, мотивируя это незнанием языка.
Лично я несколько дней работал с 4 утра, когда нужно было для личных дел немного режим подвинуть, и никаких проблем не возникло. Но людей в штате много, да.
Касательно рамок — вы правы, но задаются они ответственностью и здравым смыслом каждого конкретного сотрудника и не регламентируются свыше.
Хорошо, что есть компании, которые позволяют каждому сотруднику работать в своем индивидуальном графике. Надеюсь, что пройдет какое-то время, и управленцы догадаются, что сняв рамки «рабочего графика» с сотрудников они получат больше ресурсов, чем получают вынуждая работников ходить на работу в условные «с десяти до семи».
Так и в работе над открытым продуктом тоже могут быть свои обязательства, которые необходимо завершить перед выходом: например, почти пофикшенный баг еще не оформлен в виде пулл-реквеста.
Присоединюсь про ЕМС в Москве. Лично я после пары недель безуспешных попыток получить свою посылку поступил следующим образом: нашел недалеко от дома машину этого самого ЕМСа, и попросил водителя мне помочь. Ценой в 500 рублей удалось решить вопрос в тот же день.
Я, возможно ошибочно, пришел к тому, что насиловать свое я, пытаясь вписаться в какие-то противопрокрастинационные методики — бессмысленно. Лучше полениться пол часика, и показать хорошу производительность в течение пары часов после, чем весь день бороться с самим собой.
И что будет, если в релизе выкатится фатальная ошибка какой-нибудь жутко популярной ручки, не заддосит ли ваш механизм сбора ошибок?
Кажется, это ключевое. Действительно, если проектная команда небольшая, то договориться легко. А если ресурсов требуется больше, то никто не мешает разбить команду на подкоманды и договариваться локально. Пересечения у графиков найти можно всегда.
То есть примеры Ваши в отрыве от контекста звучат здраво, но на практике как минимум конкретно в моем случае не воспроизводятся.
Вообще более чем за год подобной работы не сталкивался с описанными вами проблемами, кажется, если они потенциально возможны — значит, либо какие-то люди не подходят для работы в распределенной команде со свободным графиком, либо проблемы с мотивацией персонала.
Но есть проблема не в подходе в целом, а в конкретной его реализации.
Спасибище за перевод, смогу попробовать мотивировать смотреть тех, кто отказывался от просмотра, мотивируя это незнанием языка.
Касательно рамок — вы правы, но задаются они ответственностью и здравым смыслом каждого конкретного сотрудника и не регламентируются свыше.
Конкретно в моей команде время прихода разнится от 8 утра до 13-14 дня, и нормально работаем.