В том то и дело, что если по сути ты — Senior Developer, просто у вас в компании грейды не приняты, так и пиши — не промахнешься. HR пройдешь, а собеседование выявит кто ты такой.
Когда клиент один, и деньги шлет сразу на карту — уже лучше, но все равно меньше чем 40 выйдет.
Хотя смотря как биллить, конечно. Если таймер не выключать когда выходишь в туалет, встаешь чаю попить — можно наверное и все 60 в неделю наработать почти не напрягаясь.
Потому что у фрилансера реально оплачивается не больше, чем 50-70% потраченного на работу времени.
Это 20-25ч в неделю из 40 потраченных. Остальное — накладные расходы. В начале этой ветки человек хорошо расписал: habrahabr.ru/company/payoneer/blog/256323/#comment_8387499
Я из chef sugar использую только compile_time, на самом деле :-)
Проблемы могут быть, если например, конфиг кривой и сервис не поднялся, и при этом инитскрипт кривой — эти случаи и имеет смысл тестировать серверспеком.
Только сейчас заметил, в шеф теперь подобного рода тестирование встроено, можно запускать серверспеки в конце применения кукбуков, или например верифицировать конфиги прямо в ресурсе: docs.chef.io/release_notes.html
Serverspec относительно неплох, если спеки держать отдельно от кукбуков.
Описываем в спеках приемочное состояние сервера, а в кукбуках уже его реализуем.
На каком-то семинаре слышал интересную мысль про оценку сроков — всегда стараться оценивать точно, а то, что нам часто требуется дополнительное время на багфиксы и доработки закладывать отдельной задачей с отдельными оценками сроков. Тогда эффекта переведенных часов не будет.
Заметил момент небольшой в вашем решении — если говорить «уволят меня в первую очередь», надо это еще донести и начальству. Иначе может выйти, что все провалили, а меня просто перевели на другой проект.
Да и то, что часть людей может сразу из проекта начать выходить, тоже сразу нужно с начальством и, вероятно, с заказчиком обговорить, т.к. у нас по этой причине может возникнуть провал по производительности.
1. Сообщить, что мы провалили сроки два раза подряд и это очень плохо — пообещали расформировать отдел, неизвестно все ли при этом останутся в компании. Донести это ясно, но долго не останавливаться, чтобы руки не начали опускаться.
2. Послушать предложения команды как исправить ситуацию с провалами.
3. Выяснить какая неучтенная работа помешала выпустить каждую из продуктов вовремя и выделить ее как отдельную задачу с отдельными же оценками. При спуске сверху новых требований всегда явно давать заказчику выбор — сроки или новые требования и обозначать риски.
4. Несмотря на то, что вы говорите, что какой-то одной проблемы выявить не удалось, все указанные проблемы кроме срыва сроков (которые мы должны были учесть в п.3) так или иначе связаны с собственно деплоем — изменением работающей у заказчика версии (а также с воспроизводимостью продакшна локально у программистов и тестеров, но это более глобальная задача и часто требует отдельной большой работы и отдельного человека на нее)
Здесь можно провести такие изменения:
* отвести на деплой время в планировании как на отдельную задачу (если он долгий) — чтобы все фичи и их тестирование закончить к этому моменту, а не к формальному концу итерации
* перенести время деплоя на время, которое создаст наименьшее количество проблем заказчику (например, ночью/в выходные — отдельно придется утрясти взаимозачет по этому времени с командой)
* договориться, что во время деплое вся команда сидит и ждет багов, чтобы их экстренно фиксить (или дежурные люди, если у всех есть квалификация фиксить все)
* В более дальней перспективе (если до этого доживем) исправить процесс стандартизирования конфигураций, тестирования, снятия метрик и мониторинга и собственно самого деплоя
Хотя смотря как биллить, конечно. Если таймер не выключать когда выходишь в туалет, встаешь чаю попить — можно наверное и все 60 в неделю наработать почти не напрягаясь.
Это 20-25ч в неделю из 40 потраченных. Остальное — накладные расходы. В начале этой ветки человек хорошо расписал: habrahabr.ru/company/payoneer/blog/256323/#comment_8387499
Просто не хочет.
Если много переключаться между задачами, то еще меньше.
Естественно, если ориентироваться на 40 реальных часов в неделю, потраченных на работу.
Проблемы могут быть, если например, конфиг кривой и сервис не поднялся, и при этом инитскрипт кривой — эти случаи и имеет смысл тестировать серверспеком.
Только сейчас заметил, в шеф теперь подобного рода тестирование встроено, можно запускать серверспеки в конце применения кукбуков, или например верифицировать конфиги прямо в ресурсе: docs.chef.io/release_notes.html
Serverspec относительно неплох, если спеки держать отдельно от кукбуков.
Описываем в спеках приемочное состояние сервера, а в кукбуках уже его реализуем.
А в чем проблемы с chef-sugar?
Да и то, что часть людей может сразу из проекта начать выходить, тоже сразу нужно с начальством и, вероятно, с заказчиком обговорить, т.к. у нас по этой причине может возникнуть провал по производительности.
2. Послушать предложения команды как исправить ситуацию с провалами.
3. Выяснить какая неучтенная работа помешала выпустить каждую из продуктов вовремя и выделить ее как отдельную задачу с отдельными же оценками. При спуске сверху новых требований всегда явно давать заказчику выбор — сроки или новые требования и обозначать риски.
4. Несмотря на то, что вы говорите, что какой-то одной проблемы выявить не удалось, все указанные проблемы кроме срыва сроков (которые мы должны были учесть в п.3) так или иначе связаны с собственно деплоем — изменением работающей у заказчика версии (а также с воспроизводимостью продакшна локально у программистов и тестеров, но это более глобальная задача и часто требует отдельной большой работы и отдельного человека на нее)
Здесь можно провести такие изменения:
* отвести на деплой время в планировании как на отдельную задачу (если он долгий) — чтобы все фичи и их тестирование закончить к этому моменту, а не к формальному концу итерации
* перенести время деплоя на время, которое создаст наименьшее количество проблем заказчику (например, ночью/в выходные — отдельно придется утрясти взаимозачет по этому времени с командой)
* договориться, что во время деплое вся команда сидит и ждет багов, чтобы их экстренно фиксить (или дежурные люди, если у всех есть квалификация фиксить все)
* В более дальней перспективе (если до этого доживем) исправить процесс стандартизирования конфигураций, тестирования, снятия метрик и мониторинга и собственно самого деплоя