В статье не хватило сравнения базовых операций, на которые обычно требуется наибольший процент времени и ошибок
Хотим как раз съезжать с планфакта, потому что нельзя без приколов сделать базовую связку для аутсорса, работающего по T&M: - сгенерировать счет - привязать платеж по этому счету к проекту - разбить начисление в рамках этого платежа на сколько расчётных периодов
Есть всякие обходные пути через создание сделок, которые живут параллельно с проекта. Но тогда надо сначала создать сделку, сгенерить в ней счёт, потом отвязать платёж от сделки, привязать в проекту и там уже разбить по начислениям
И как следствие - ошибки при внесении и торможение с генерацией доков на оплату
Вроде у адеска с этим получше + с учётом анализа затрат на зп в разрезе налогов, на руки и конкретных сотрудников совсем хорошо. Но не доходят руки проанализировать остальные сервисы на предмет этих базовых сценариев
Про полгода я сказал в плане цикла постановки целей по матрице компетенций для каждого уровня разработчика. Это не одна цель, а пласт знаний и навыков, которые нужно освоить чтобы перейти на следующий грейд
А насчёт багов если бы всё было так просто... Один баг мог возникнуть из-за недостаточного описания задачи, другой - из-за невнимательного прочтения детально описанной задачи, третий - из-за того что разработчика отвлекли на срочный созвон, четвертый - из-за переключения на другую задачу...
Список можно продолжать если не бесконечно, то точно долго и там конечно могут быть и причины вроде "не хватило определённого навыка, чтобы оптимально решить задачу", но тут же сразу идёт вопрос - "а почему именно этот разработчик выполнял эту задачу, а не более квалифицированный и почему эта проблема не была выявлена на этапе проверки кода коллегой?"
А если на всё это ещё наложить дисперсию из-за разных типов проектов и разных приоритетов заказчиков в конкретный момент ("мне полюбому надо запуститься к дедлайну, пусть и с багами" / "срочности нет, важно чтобы всё было вылизано до мелочей"), то прямой вывод из количества багов конкретных команд произвести вообще невозможно
Это действительно очень полезная штука, мы сами делаем траекторию для сотрудников и раз в полгода её корректируем.
Единственный нюанс - этот подход имеет ещё более отложенный эффект чем изменения процессов. Ну и объективная работа по отклонениям возможна только при объективной оценке скорости разработки, что само по себе сложная задача
В статье речь не про запуск во время январских праздников, а в период после нового года до гендерных праздников - крупные бренды ещё не запланировались, а люди уже отошли от новогоднего состояния.
Это не 8 дней, а полтора месяца, в которые мы можем успеть разработать и запустить игру
В минимальной комплектации запуск готовой механики выходит 275 тыс на разработку плюс затраты на трафик. Верхний потолок не ограничен - сделаем хоть космолёт :)
Насчёт срока окупаемости сложно ответить что-то вроде "окупится за 10/50/100 дней", потому что основные затраты идут на закупку трафика, а доход зависит от маржинальности вашего товара / услуги
Термином "сервер" я сознательно упростил менее понятное "окружение". Технически это всё развертывается в кубернетесе и билд пропускается через стандартный процесс CI/CD, где запускаются все автотесты
Мы занимаемся в основном веб и мобильной разработкой, статья про именно про веб проекты. Поэтому задачи про тестирование на нескольких архитектурах и платформах не стоит. Но в остальном всё делаем также как вы и сказали
У Вебиума большая группа ВКонтакте, на 85 тыс подписчиков, в которой промоутировалось приложение
https://vk.com/webium_ege
Но обычно для промо миниаппов еще подключается платный трафик внутри ВК
Не всё так просто, но вообще это уже сделано https://habr.com/ru/companies/whoosh/articles/707176/
В статье не хватило сравнения базовых операций, на которые обычно требуется наибольший процент времени и ошибок
Хотим как раз съезжать с планфакта, потому что нельзя без приколов сделать базовую связку для аутсорса, работающего по T&M:
- сгенерировать счет
- привязать платеж по этому счету к проекту
- разбить начисление в рамках этого платежа на сколько расчётных периодов
Есть всякие обходные пути через создание сделок, которые живут параллельно с проекта. Но тогда надо сначала создать сделку, сгенерить в ней счёт, потом отвязать платёж от сделки, привязать в проекту и там уже разбить по начислениям
И как следствие - ошибки при внесении и торможение с генерацией доков на оплату
Вроде у адеска с этим получше + с учётом анализа затрат на зп в разрезе налогов, на руки и конкретных сотрудников совсем хорошо. Но не доходят руки проанализировать остальные сервисы на предмет этих базовых сценариев
Главное, чтобы была охапка дров!
Зато хоть есть что рассказать)
Да, это описано в разделе "короткий путь. Доступ к гугл документам и гугл встречам за 5 минут"
Макс — Легенда!
Спасибо!
Рекомендация подходит для любых сервисов, так что согласен:)
Face ID сервис как раз и используется, в данном случае встроенный в домофон
Безопасность при распознавании человека обеспечивается встроенными в домофон механизмами
Спасибо!
Заходите в аккаунт, там есть еще :)
Про полгода я сказал в плане цикла постановки целей по матрице компетенций для каждого уровня разработчика. Это не одна цель, а пласт знаний и навыков, которые нужно освоить чтобы перейти на следующий грейд
А насчёт багов если бы всё было так просто... Один баг мог возникнуть из-за недостаточного описания задачи, другой - из-за невнимательного прочтения детально описанной задачи, третий - из-за того что разработчика отвлекли на срочный созвон, четвертый - из-за переключения на другую задачу...
Список можно продолжать если не бесконечно, то точно долго и там конечно могут быть и причины вроде "не хватило определённого навыка, чтобы оптимально решить задачу", но тут же сразу идёт вопрос - "а почему именно этот разработчик выполнял эту задачу, а не более квалифицированный и почему эта проблема не была выявлена на этапе проверки кода коллегой?"
А если на всё это ещё наложить дисперсию из-за разных типов проектов и разных приоритетов заказчиков в конкретный момент ("мне полюбому надо запуститься к дедлайну, пусть и с багами" / "срочности нет, важно чтобы всё было вылизано до мелочей"), то прямой вывод из количества багов конкретных команд произвести вообще невозможно
Отличное дополнение, спасибо!
Это действительно очень полезная штука, мы сами делаем траекторию для сотрудников и раз в полгода её корректируем.
Единственный нюанс - этот подход имеет ещё более отложенный эффект чем изменения процессов. Ну и объективная работа по отклонениям возможна только при объективной оценке скорости разработки, что само по себе сложная задача
Вот у нас тоже давно реализовано, но недавно поняли что есть много компаний, для которых это всё ещё не является стандартом
На то он и идеальный мир:) но к этому можно и нужно стремиться, хотя бы не в плане незавершенной работы в целом.
Когда одну фичу тестят тестировщики, по другой код смотрит ревьюер, по третьей пришли баги, но вот именно в разработке одна фича
У нас в целом такая схема сохраняется если нет каких-то из ряда вон выходящих событий
Спасибо:)
Оригинальный отклик:)
Наоборот старались рассказать полезную информацию про крутой кейс
Должно быть полезно для тех, кто задумывается о разработке мобильного приложения для технадзора или для других полевых сотрудников
В основном по рекомендациям:)
KTS основали разработчики, поэтому поиск разработчиков по рекомендациям был основным каналом привлечения сотрудников в то время
Сейчас набираем с рынка, по рекомендациям и через собственную школу, писал о ней в отдельной статье https://vc.ru/life/639896-kak-nanimat-razrabotchikov-cherez-shkolu-nashi-vyvody-za-6-let-obucheniya-2600-studentov-i-50-nanyatyh-stazherov
С Никитой Литвинковым
Например, оператор Lovit, который в новостройки ПИКа проводит интернет
Не всё интернет провайдеры масштабом с мгтс, так что всё логично
You are welcome!
В статье речь не про запуск во время январских праздников, а в период после нового года до гендерных праздников - крупные бренды ещё не запланировались, а люди уже отошли от новогоднего состояния.
Это не 8 дней, а полтора месяца, в которые мы можем успеть разработать и запустить игру
В минимальной комплектации запуск готовой механики выходит 275 тыс на разработку плюс затраты на трафик. Верхний потолок не ограничен - сделаем хоть космолёт :)
Насчёт срока окупаемости сложно ответить что-то вроде "окупится за 10/50/100 дней", потому что основные затраты идут на закупку трафика, а доход зависит от маржинальности вашего товара / услуги
В каждом симптоме описал, почему такое происходит и как это решить :)
Даже специально жирным выделил "хорошее решение" :))
Подтверждаю, всё так:)
Термином "сервер" я сознательно упростил менее понятное "окружение". Технически это всё развертывается в кубернетесе и билд пропускается через стандартный процесс CI/CD, где запускаются все автотесты
Мы занимаемся в основном веб и мобильной разработкой, статья про именно про веб проекты. Поэтому задачи про тестирование на нескольких архитектурах и платформах не стоит. Но в остальном всё делаем также как вы и сказали