Да, действительно, в жизни каждого менеджера иногда бывает такой момент, когда надо выбрать - дедлайны или 40% команды. И да, разумеется, чаще всего выбор делается в пользу дедлайнов.
Ну и? Такова жизнь. Таков бизнес. Для того таких людей и нанимают. Кто-то в команде должен отвечать за комфорт, а кто-то - за реальные решения, ведущие к прибыли. Иначе не будет и комфорта тоже.
Жаль, конечно, бедолагу Антона, которому из-за перевода на другой проект пришлось "оказаться длительно нетрудоспособным и мучительно перекраивать свой образ жизни после дорогого и долгого курса лечения". Но уж больно он смахивает на выдуманного персонажа.
Пожалуй не стоит называть аппарат с ядерной энергоустановкой на борту громкими словами "с ядерным двигателем". Двигателем там будет, скорее всего, банальный ксеноновый ионник.
Сначала создаем себе бутылочное горлышко, в виде неявного утверждения, что релиз в один момент времени может быть ровно один, а затем героически его преодолеваем.
Система релизов вообще имеет смысл только в том случае, если у вас релизы параллельные: то есть в один момент времени может существовать сколько угодно параллельных готовящихся релизов, вы умеете с нулевыми трудозатратами добавлять в них задачи, удалять, перекидывать из релиза в релиз, если у вас нулевые трудозатраты на развертывание произвольного количества релизных стендов (для каждого из готовящихся параллельных релизов!), и есть некий процесс выбора из множества релизов одного, готового к деплою на прод, и этого самого деплоя (а вот сам деплой в общем случае не обязан быть полностью автоматизирован).
Без параллелизации процесса и без принципа "релизим то, что готово, а не готовимся в релизу", вы вечно будете застревать в узких местах производительности команды, когда "у нас семь программистов пишут в одну QA".
>> В этой очереди только люди, которые не могут платить
Не хочу вас разочаровывать, но такое явление, как "выкуп" сканов из архивов весьма развито. Буквально недавно лично участвовал в сборе, более чем на 50 000 рублей за одно конкретное дело.
И ничего, нашлись желающие заплатить. И нашелся архив, готовый оплату принять.
Я могу поделиться с вами ресурсом на тестирование вашего решения. Есть доступ к архивам, есть целевые сканы, распознавание которых востребовано, есть и тестировщики, которые смогут это проверять.
Более того, я прекрасно представляю как это всё можно монетизировать. Очередь на распознавание метрических книг, исповедных росписей и прочих генеалогических документов - стоит до горизонта.
Но пока, если честно, я не вижу, с чего тут даже начать, нынешнее распознавание в половину букв даже не попадает.
Искренне желаю вам удачи, но пока что качество распознавания оставляет желать лучшего и, если честно, ничем не отличается от других инструментов.
Если посимвольно примерно половину символов инструмент распознает, то пословно - полный провал, конечно. Даже в печатном тексте, не говоря о рукописном.
Вот пример: метрическая книга начала 20 века. Почерк весьма читаемый, разборчивый. Результат - плачевный.
>> много времени уходит не на код, а на уточнения, гипотезы и согласования Тарифицируйте это время по ставке достаточного дорогого руководителя проекта со своей стороны и, о чудо - непроизводительные затраты начнут сокращаться ))
Нет, не всё. В вашей юрконструкции упущен очень важный, даже ключевой документ - заказ.
Без документа, который явно называется "Заказ", исходит от заказчика (!) и содержит его требования по составу, объему и ориентировочной стоимости услуг на очередной период - вы однажды попадете в ситуацию, когда вам заказчик не подпишет очередной акт, мотивируя это тем, что он ваши услуги не заказывал и что работы вы делали по собственной инициативе и за свой же счет.
Ваш "допник" имеет похожий смысл, но это немного не то.
Ну и в целом T&M требует ряда специфичных моментов в договоре, о которых вы не упомянули, а зря.
В качестве имени группы сериализации очень удобно использовать имя контроллера, которому сериализация потребовалась:
Ровно ничего плохого о нем это не говорит.
Поставлена задача - задача выполнена. Документация есть, бас-фактор устранен. И даже никто не уволен - чела перевели на другой проект.
Хороший менеджер, годный. Молодец.
У каждого горизонта планирования - свой ответственный. Вряд ли линейный менеджер отвечает за стратегические планы, согласитесь?
Прочёл дважды, но так и не понял, что плохого.
Да, действительно, в жизни каждого менеджера иногда бывает такой момент, когда надо выбрать - дедлайны или 40% команды. И да, разумеется, чаще всего выбор делается в пользу дедлайнов.
Ну и? Такова жизнь. Таков бизнес. Для того таких людей и нанимают. Кто-то в команде должен отвечать за комфорт, а кто-то - за реальные решения, ведущие к прибыли. Иначе не будет и комфорта тоже.
Жаль, конечно, бедолагу Антона, которому из-за перевода на другой проект пришлось "оказаться длительно нетрудоспособным и мучительно перекраивать свой образ жизни после дорогого и долгого курса лечения". Но уж больно он смахивает на выдуманного персонажа.
Пожалуй не стоит называть аппарат с ядерной энергоустановкой на борту громкими словами "с ядерным двигателем". Двигателем там будет, скорее всего, банальный ксеноновый ионник.
Ядерные реакторы в космосе летают уже давно. См. проекты "Бук" и "Топаз", к примеру.
Сначала создаем себе бутылочное горлышко, в виде неявного утверждения, что релиз в один момент времени может быть ровно один, а затем героически его преодолеваем.
Система релизов вообще имеет смысл только в том случае, если у вас релизы параллельные: то есть в один момент времени может существовать сколько угодно параллельных готовящихся релизов, вы умеете с нулевыми трудозатратами добавлять в них задачи, удалять, перекидывать из релиза в релиз, если у вас нулевые трудозатраты на развертывание произвольного количества релизных стендов (для каждого из готовящихся параллельных релизов!), и есть некий процесс выбора из множества релизов одного, готового к деплою на прод, и этого самого деплоя (а вот сам деплой в общем случае не обязан быть полностью автоматизирован).
Без параллелизации процесса и без принципа "релизим то, что готово, а не готовимся в релизу", вы вечно будете застревать в узких местах производительности команды, когда "у нас семь программистов пишут в одну QA".
Вы не выкупаете мета-иронию.
Так-то и PHP написан на C.
85?
Смеюсь в голос.
Попытка в Москве нанять в офис QA без особых специфичных требований приводит к более, чем 1000 (!!!) откликов в день.
Правда из них примерно 950 - это не Москва, не офис и не QA, но это уже мелочи.
Беда, коллеги, в том, что вы не слышите вторую сторону. Уход из удаленки в офисы (назад) вполне себе рационален и экономически обоснован.
Но писать об этом на Хабре - это хабросуицид. Вы же мгновенно обнулите карму каждого, кто постарается беспристрастно посмотреть на вопрос.
Вот и появляются такие статьи, где авторы "негодуют" и "не понимают". А вы спросите - почему? Но будьте готовы услышать ответ.
>> В этой очереди только люди, которые не могут платить
Не хочу вас разочаровывать, но такое явление, как "выкуп" сканов из архивов весьма развито. Буквально недавно лично участвовал в сборе, более чем на 50 000 рублей за одно конкретное дело.
И ничего, нашлись желающие заплатить. И нашелся архив, готовый оплату принять.
Вы недооцениваете размеры архивов. Проекты по их индексации имеются, но нынешними темпами на это потребуются столетия.
Я могу поделиться с вами ресурсом на тестирование вашего решения. Есть доступ к архивам, есть целевые сканы, распознавание которых востребовано, есть и тестировщики, которые смогут это проверять.
Более того, я прекрасно представляю как это всё можно монетизировать. Очередь на распознавание метрических книг, исповедных росписей и прочих генеалогических документов - стоит до горизонта.
Но пока, если честно, я не вижу, с чего тут даже начать, нынешнее распознавание в половину букв даже не попадает.
Искренне желаю вам удачи, но пока что качество распознавания оставляет желать лучшего и, если честно, ничем не отличается от других инструментов.
Если посимвольно примерно половину символов инструмент распознает, то пословно - полный провал, конечно. Даже в печатном тексте, не говоря о рукописном.
Вот пример: метрическая книга начала 20 века. Почерк весьма читаемый, разборчивый. Результат - плачевный.
>> 2. Сам будет массово откликаться на релевантные вакансии и писать уникальные сопроводительные письма.
Отлично. Давайте доломаем механики найма окончательно.
Пусть теперь в сутки на вакансию QA Middle будет благодаря вам не 500 откликов, а 5000. И работодатели окончательно плюнут на найм и уйдут в аутстафф.
Не очень понятен ваш вопрос. Для многих это не возможность - это текущая реальность.
Единственный реальный аргумент "за" удалёнку - это возможность работать на несколько работодателей.
И это же является единственным реальным аргументом "против". Но уже с другой стороны.
Всё остальное - социально приемлемый буллшит.
Meethub
Как Pornhub, только Meet ))
Если кто-то захочет затестить все фичи, а не только ограниченные бесплатным тарифом или затащить к себе в закрытый контур - обращайтесь.
>> много времени уходит не на код, а на уточнения, гипотезы и согласования
Тарифицируйте это время по ставке достаточного дорогого руководителя проекта со своей стороны и, о чудо - непроизводительные затраты начнут сокращаться ))
>> Всё
Нет, не всё. В вашей юрконструкции упущен очень важный, даже ключевой документ - заказ.
Без документа, который явно называется "Заказ", исходит от заказчика (!) и содержит его требования по составу, объему и ориентировочной стоимости услуг на очередной период - вы однажды попадете в ситуацию, когда вам заказчик не подпишет очередной акт, мотивируя это тем, что он ваши услуги не заказывал и что работы вы делали по собственной инициативе и за свой же счет.
Ваш "допник" имеет похожий смысл, но это немного не то.
Ну и в целом T&M требует ряда специфичных моментов в договоре, о которых вы не упомянули, а зря.