T2m что это в бизнесе
T2m что это в бизнесе
Один наш клиент постоянно не успевал вовремя выпускать релизы (обновления и новый функционал программного обеспечения) с клиентскими скидками. Его специалисты работали по 14–16 часов в выходные и ненавидели «черные пятницы» и «киберпонедельники». Качество выпускаемого в таком режиме программного обеспечения оставляло желать лучшего, работу в выходные приходилось оплачивать по двойному тарифу, продуктивность падала, сотрудники уставали и увольнялись, покупатели, натыкаясь на критические ошибки при совершении покупок, злились и уходили на сайты других компаний.
При этом ФОТ составлял 13,5 млн рублей в месяц, выпуск «срочного» релиза занимал 2 месяца, релиз в среднем содержал 1–3 блокирующих и до 10 критичных проблем системы, что приводило к репутационным и финансовым потерям.
В попытке разобраться, в чём же причина такого долгого и проблемного релизного цикла, заказчик обратился к нам. Выполнив аудит, мы обнаружили стандартную историю, в которой каждый наверняка найдет знакомые детали: много ручного труда (начиная со сборок и наката релиза на тестовую среду и заканчивая подготовкой тестовых данных); отсутствие автоматизированного тестирования; низкая квалификация сотрудников; наличие полной экспертизы лишь у одного человека, который руководствуется исключительно своими приоритетами (узкое горлышко); нежелание что-то менять; пропасть между ИТ и бизнесом в попытке понять, почему всё так долго и так плохо.
В первую очередь мы занялись основными процессами: выделили самые критичные бизнес-сценарии, автоматизировали их проверку; реализовали автосборку; настроили автораскатку на стенды разработки, тестирования и на продуктив; автоматизировали подготовку тестовых данных; разбили проверки на важные и менее важные, важные начали автоматизировать; команда ручного тестирования получила список самых важных проверок при нехватке времени. К окончанию проекта мы имели 92% автоматизированных проверок из всего объема и смогли сократить команду тестирования на 30%. Разработчики же, освободившись от необходимости тратить время на ручные сборки и раскатки, начали выполнять больший объем работы за тот же период.
Сотрудники счастливы и проводят выходные с семьей, никто не увольняется, бизнес получает свои изменения вовремя и с достойным качеством, у покупателей нет проблем при выборе и покупке товаров на сайте.
Наряду с этим, время вывода среднего релиза сократилось до 2 недель при 30-процентной экономии ФОТ и выводе качества среднего релиза на уровень 0 блокеров, 0–5 критичных багов! Проект обошелся заказчику в один месячный ФОТ текущей ИТ-команды, занял 3,5 месяца и окупился примерно через 2 месяца после внедрения.
Одна крупная компания потеряла 200 млн рублей, выпустив плохо протестированный релиз в продуктив. Причиной этого стала попытка сэкономить на персонале (ФОТ, операционные затраты): тестировщик-стажер халатно отнесся к выполнению тест-кейса — пометил интеграционный кейс как пройденный, ничего на самом деле не проверив. «Честное» ручное прохождение теста заняло бы 15 минут с проверкой настроек системы и логов. Автоматизированный тест занял бы менее 1 минуты плюс пару минут на выяснение, в чём проблема. Цифры и удивляют, и убивают одновременно.
Всегда существует человеческий фактор: люди ошибаются, не высыпаются, ссорятся с женами/мужьями, просто не в настроении, наконец. Поэтому, автоматизируя процессы, мы убиваем двух зайцев: ускоряем процесс и обеспечиваем качество, исключая тот самый человеческий фактор. Автоматизация одного сквозного сценария (с проверкой интеграционных значений) занимает от 2 до 16 часов (в зависимости от сложности). Поэтому решительно непонятно, зачем многомиллиардная компания сэкономила на мелочи, получив потом такие убытки.
Добавим чуть-чуть технических деталей. Чем раньше найдена ошибка в программном обеспечении, тем дешевле обойдется работодателю ее исправление, так как:
1. Разработчик всё еще работает над тем же куском программного кода, он еще не забыл, что делал месяц назад, ему не нужно переключаться между контекстами, и правку он делает буквально «на лету».
2. Другие разработчики не вносят изменения в этот содержащий ошибки программный код.
3. Ветки кода не успели размножиться на последующие релизы, и не нужно будет исправлять один и тот же баг сразу в нескольких местах, учитывая версионность кода.
4. Тестировщик еще не успел потратить время на долгое регрессионное тестирование, которое придется повторять после исправления найденной ошибки.
Маленький пример такой экономии для среднеразвитой системы, изменения в которую вносятся 1 раз в 2 месяца, представлен в таблице.
Умножьте эти цифры на ваш текущий ФОТ ИТ-команды и время вывода изменений в продуктив, и вы узнаете ваши потери.
В век информационных технологий трудно переоценить важность скорости, с которой компании могут внедрять изменения. На рынке всегда найдется пара конкурентов, которые сделают это быстрее или лучше.
Какой путь выберет компания и знает ли она о текущих возможностях?
Можно идти пешком. Можно воспользоваться транспортным средством: велосипедом, машиной, — но без учета пробок на дороге такое движение может оказаться значительно продолжительнее по сравнению с движением пешехода.
Конечно, вопрос о том, как добраться до цели в нужные сроки, правильно выбирая средства и обеспечивая оптимальные затраты, должны решать профессионалы, ведь иногда промедление смерти подобно.
У любой (не только из сферы ИТ) компании это может быть выпуск нового продукта для сохранения конкурентного преимущества при участии в тендере, если речь идет о B2B, или компания просто решила сделать продукт более привлекательным для существующих или новых клиентов в случае B2C.
В конце концов, это могут быть банальное обеспечение соблюдения сроков для устранения замечаний регулятора или доработка решения к какой-то фиксированной дате в связи с введением в действие нового законопроекта. В таких случаях, если компания не успела внести изменения в срок, приостанавливается действие ее лицензии, у нее нет деятельности, нет прибыли, она теряет клиентов.
Важно понимать, что все инструменты, методологии и подходы можно применять и по отдельности — они однозначно будут давать эффект и уменьшать время вывода продукта на рынок. Но наибольший эффект мы можем получить, только применяя все подходы сразу, — тогда сокращение Time to Market (T2M) может стать максимально большим за счет эффективности каждого из процессов.
Для среднего релиза (3 командо-месяца) картинка будет примерно такая: автоматизировали сборку — сэкономили 5% ФОТ и T2M, автоматизировали подготовку тестовых данных — сократили 10% ФОТ и T2M, автоматизировали smoke test — еще 5% ФОТ и T2M, регресс — 10–15%. Добавьте в этот коктейль гибкие методологии разработки, и получите свои законные 40–50% экономии ФОТ и времени вывода релиза.
При этом для системы средней сложности (и ее интеграционных взаимодействий) сам проект занимает не более 4 месяцев, а окупается уже за 2–3 месяца.
Когда непрофильные компании берутся за разработку ПО, они заново изобретают велосипед, не понимая, как улучшить процесс и сделать его по-настоящему эффективным. Как большинство не ИТ-компаний работает сейчас (см. рис. 1).
А вот как должно быть (см. рис. 2).
Правило простое: любое повторяющееся из раза в раз действие должно быть автоматизировано и настроено на регулярный запуск (по расписанию или событию), что позволяет сократить и время, и количество людей, поддерживающих данную рутину.
Кроме того, мы исключаем человеческий фактор: скрипт выполняет одно и то же действие из раза в раз, не устает, у него «не замыливается глаз», он не допускает ошибок, работает по выходным и по ночам — и даже не просит оплаты сверхурочных.
И да, в скором времени нас всех заменят роботы.
В завершение хочется сказать, что даже в одной компании может быть несколько десятков систем, находящихся на разном уровне развития в части автоматизации процессов.
Текущая картина в системе определяется при помощи ключевых точек в процессе разработки и тестирования, и мы легко можем сказать, находится ли система на нулевом уровне развития или она уже на стадии зрелых процессов и относится к продвинутому уровню.
Переход с начальных уровней на высокие, безусловно, дает максимальный и зримый эффект. Для того чтобы понять, на каком уровне развития (зрелости) находится та или иная система, в нашей компании используется четкая методика оценки, из которой легко вычленить цели и результаты, которых мы хотим добиться, автоматизируя процессы в системе. Так заказчик проверяет результаты внедренных изменений, опираясь на четкие KPI. Так он получает ясное представление о тех изменениях, которые будут внесены в процесс.
В настоящее время многие компании-интеграторы начинают предлагать свои услуги в области автоматизации процесса разработки и тестирования. Уже не такими новыми выглядят термины DevOps, CI/CD, pipeline, agile — даже для не ИТ-управленцев. О себе в контексте данной темы мы можем скромно сказать, что съели на этом собаку, кошку и даже маленького слона.
Материал подготовлен Ольгой Шишелиной, руководителем отдела тестирования Дирекции по разработке и внедрению программного обеспечения компании «Инфосистемы Джет»
Time & material — мечта и боль разработчика
Виды T&M
Для T&M контрактов существует широкий спектр форматов реального взаимодействия. Два самых ярких представителя:
Почти аутстафф: исполнитель поставляет ресурсы, которые делают то, что сказал заказчик. Бюджета нет, есть месячный платеж на покрытие стоимости команды. От полноценного аутстаффа этот формат может отличаться тем, что на стороне исполнителя находится тимлид и детальная постановка задачи.
Почти фикс: есть скоуп, твердый бюджет, на стороне исполнителя сформирована проектная команда, но планирование идет по принципу беклога, работа формируется в спринты. Детализация постановки, а также решение о глубине реализации той или иной функции идет в процессе работы. Очень похоже на agile, вам не кажется.
За что платит заказчик
Сама аббревиатура T&M обозначает Time and Material — оплату за время и иные потраченные ресурсы.
Иногда в рамках T&M оплачивается все рабочее время сотрудника, вне зависимости от того, что он делает и делает ли вообще. Исполнитель будет настаивать на такой трактовке, когда детальное (позадачное) планирование работы команды находится в руках клиента: если контрактоваться иначе, то у заказчика не возникнет ответственности за неэффективную работу или простой сотрудников, и он гарантированно будет этой возможностью злоупотреблять.
Другой формат — оплачиваются только конкретные работы из плана, акцептованные заказчиком. Детальное проектное управление находится в руках исполнителя, он же распределяет задачи на сотрудников. Такой формат предполагает, что у проекта есть запас дел не менее чем на 2-3 горизонта планирования. При этом менеджер, оценивая объем работы, по согласованию с клиентом, может корректировать размер команды.
Схема фиксации плана работ и задач
На старте проекта должен быть оговорен механизм принятия задач. Скоуп и объем работ на T&M раздувается очень быстро, и причина проста: у заказчика всегда есть неисчерпаемый запас идей и желаний, а исполнитель только и рад увеличить счет в сторону клиента, реализуя все мыслимые и немыслимые мечты.
При этом очень легко образуется треугольник разорванной ответственности: менеджер продукта (от заказчика) струится мечтами, менеджер проекта (от исполнителя) делает все, чтобы его ублажить, а когда счет двойного размера попадает в финансовый контроль к клиенту, менеджер продукта быстро бледнеет и заявляет, что он всего этого не заказывал. Вот огурцы и лучок — да, а шашлык по-царски и односолодовый виски — это исполнитель сам придумал, сам съел и сам выпил. Выкинул в пропасть.
Осложняется вся эта картина еще и тем, что любая попытка ввести на стороне исполнителя собственный финансовый контроль или управление скоупом, вызывает гнев означенного выше продакт-менеджера на первой же попытке отказать ему в реализации функции, ибо как смеет несчастный контрактатор наступать на горло его песне.
Тем не менее практика показывает, что исполнитель, работающий по контракту T&M для закрытия своих рисков, вынужден привносить в него элементы fix price проекта. Например, путем фиксации в договоре/ТЗ критического скоупа: стороны договариваются, что контракт не может считаться не исполненным, если у результата на дату Х есть пол, руль, мотор и колеса. Все остальное может быть добавлено или изъято движением мятущейся души заказчика, но не эти четыре детали. В таком раскладе исполнитель может работать с приоритетами, направляя основные силы на ключевые функции системы, и реализуя всяческие bells and whistles в рамках, например, четверти бюджета времени проекта.
Схема code freeze и формирование стабильных версий
Вторая проблема гибких проектов имеет в основе те же самые причины, но несколько иные риски на выходе. Предположим, что бюджет действительно бесконечен — редко, но так тоже бывает. Тогда нет проблемы с объемом работ, но есть даты релизов, или, хуже того, усталость заказчика более высокого уровня от ожидания. Если проект не успел к плановой дате, потому что менеджер клиента раздул скоуп, виноват будет все равно разработчик. Если реализация массы ненужных функций сделала код неуправляемым и нестабильным, никто не примет объяснений: «Вы сами так просили». Ответ заказчика будет прост: «Мы не просили делать плохо».
Риск работы с непрофессиональным сотрудником на стороне клиента
Можно быть идеальным исполнителем для менеджера со стороны клиента, но это не гарантирует успех: проект может провалить человек от заказчика. Для ИТ-компании это означает следующий риск: два года Вася из NNN говорил, что все идет идеально, а потом пришел его директор, Васю выгнал с треском, платежи остановил, потому что все это время руками подрядчика делали нечто, совершенно никому не нужное.
Такой риск в T&M проектах существенно выше, чем в фиксовых. Последний предполагает детальную работу с требованиями, а опытный аналитик никогда не забудет провести работу по выявлению реальных стейкхолдеров и выяснит, с кем, кроме Васи, нужно согласовать бизнес-цели проекта.
Нельзя рассматривать T&M контракт в режиме «мне приказали, я сделал, они обязаны заплатить». Исполнитель должен понимать бизнес-цели контракта, управлять скоупом проекта и не позволять линейным сотрудникам на стороне заказчика вести проект к неудаче. Даже если контракт и размер заказчика гарантируют оплату сколь угодно идиотской работы, кроме денег есть еще и репутация. Сделав в T&M режиме неуспешный, но оплаченный проект, можно получить недовольство на уровне руководства заказчика, кто бы ни был причиной этого неуспеха.
Разработка ПО по договору Time&Material: риски и преимущества
Руководитель студии по разработке мобильных приложений Winfox Мухамедьянов Рустам, о том как работать по договору Time&Material
Правильное построение взаимоотношений между заказчиком и исполнителем это половина успеха разработки. Подходящий для проекта тип контракта помогает минимизировать риски и увеличить шансы на положительный результат для обеих сторон: клиента и компании-разработчика. Давайте рассмотрим одну из моделей ценообразования в аутсорсинге – работу по договору Time&Material.
При упоминании Time and Material часто возникает вопрос: «Почему бы подрядчику не потянуть резину чтобы получить побольше денег?». На деле это вопрос доверия. Этот способ ценообразования позволяет исполнителю гибко настроить процесс разработки, не огораживаясь доп. костами от рисков и не возводя преград в виде строгих ТЗ перед заказчиком. Хороший исполнитель заинтересован в правильном результате и старается сохранять процессы прозрачными.
Это хороший подход когда качество продукта для клиента на первом месте и не вызывает беспокойства мысль, что может быть потрачено больше ресурсов, чем планировалось. Однако для минимизации рисков, при составлении договора по модели Time and Material, надо детализировать план разработки ПО и обсудить сроки выполнения этапов и всего цикла разработки.
T&M это модель работы, при которой оплачивается не результат, а время исполнителя. Например, вы платите не за разработку и внедрение программы управления предприятием, а за человеко-часы, потраченные сотрудниками исполнителя на разработку. Но что означает Time&Material на самом деле? Западный опыт работы по Time & Material подразумевает, что заказчик оплачивает услуги исполнителя, на основе человеко-часов, дополнительно возмещая затраты на используемые материалы.
В российской практике существуют договор подряда и договор возмездного оказания услуг. По договору подряда работа, которую выполняет подрядчик, должна быть воплощена в материальный результат, в то время как по договору возмездного оказания услуг предметом является именно процесс, который и оплачивается заказчиком.
Договор Time and Material имеет ряд особенностей:
Положительное отношение к изменениям со стороны исполнителя. Этот подход хорошо дисциплинирует заказчика и стимулирует более обдуманно планировать и проектировать проект;
Максимальная гибкость. Клиент может позволить себе делать что угодно в каких угодно объемах. Вносить изменения можно с большей скоростью;
Первое опасение возникающее у потенциального клиента – компания разработчик может раздуть время и бюджет проекта до бесконечности. Для того чтобы снять это опасение давайте рассмотрим как работают компании по модели T&M.
T&M хорошо применять там где невозможно определить полный объем работы или сроки их реализации. Для каких типов проектов рекомендуется модель T&M?
1. Проект находится на стадии тестирования, технического обслуживания или доработок. Для выполнения отдельных блоков работ T&M – очень удобный вариант. Каждую стадию можно описать в подробных ТЗ, особенно когда готова вся документация по проекту.
2. Проекты, срок разработки которых занимают до 6 месяцев, на команду от 5 человек и требуют наличия технической документации. Модель «Оплата по факту» позволяет исполнителю подстраиваться под желания клиента и требования рынка, поэтому четкие спецификации, хоть и нужные, могут отсутствовать на первых порах. Тогда документация будет писаться в ходе работы или станет первой задачей в рамках проекта.
3. Крупные проекты, которые требуют команды от 25 человек, со сроками разработки от года. В связи с большими объемами и долгим временем разработки, предварительные спецификации будут фрагментированы и могут занимать тысячи страниц, которые будут корректироваться по ходу разработки.
Концепция договора Time&Material предполагает, что вы платите, после выполнения работ по заранее определенному плану. Этапы разработки определяются в начале сотрудничества. Вот как это работает в Winfox:
M2M и IoT — ключевые технологии для современного бизнеса и потребительского рынка. Тренды М2М в 2021 году
Переход от простых межмашинных подключений (M2M) к сложному Интернету вещей (IoT) идет полным ходом, поскольку улучшение LTE IoT и развитие сетей 5G обеспечивают более быстрые соединения и более высокие битрейты. M2M и IoT — ключевые технологии для современного бизнеса и потребительского рынка. По мере того, как эти технологии продолжают развиваться, они открывают новые возможности для тех, кто понимает их и может эффективно использовать сильные стороны каждой технологии.
Технология M2M может быть лучшим выбором, если:
Рост М2М в мире
Интернет вещей (IoT) стал распространенной системой, в которой люди, процессы, данные и вещи подключаются к Интернету и друг к другу. По данным из годового отчета Cisco по Интернету M2M-соединения вырастут с 8,9 млрд (2020 год) и до 14,7 млрд к 2023 году.
Рост числа подключений M2M в мире
ABI Research, глобальная консалтинговая компания по изучению рынка технологий, подтверждает в своих последних исследованиях, что китайский производитель Quectel в настоящее время является крупнейшим поставщиком модулей сотового Интернета вещей в мире.
Однако этот успех влечет за собой новые проблемы, поскольку, оказавшись на вершине, единственный путь — это вниз. Китайские продавцы понимают, что им необходимо закрепить свой успех, и не могут рассчитывать на большие объемы и низкие цены до бесконечности.
Долгосрочное доверие зависит от качества продукции и надежности поставщика.
Повсеместно начинает действовать более строгий контроль качества и контроль затрат за счет независимого производства, дифференцированного дизайна, международных центров поддержки и целенаправленных усилий по предотвращению ценовых войн.
3 тренда M2M в 2021 году
Этот год и несколько следующих будут захватывающими для M2M. Аналитическое агентство J’son & Partners Consulting отмечает следующие тенденций M2M, на которые стоит обратить внимание в этом году и в будущем:
Мгновенная связь, надежные сети, молниеносная скорость загрузки и передачи — 5G произведет революцию в том, как потребители используют свои смартфоны, и окажет огромное влияние на все отрасли. По данным годового отчета Cisco по Интернету к 2023 году почти 60 процентов мобильных устройств и подключений во всем мире будут иметь поддержку 4G+, что в несколько раз превзойдет устройства и подключения с поддержкой 3G и ниже.
К 2023 году Северная Америка займет первое место по количеству устройств с подключением к сети 4G+, что составит 62%, в то время как Ближний Восток и Африка к этому времени будут иметь самую высокую долю своих устройств и подключений с поддержкой 3G и ниже, что составит 73%.
По прогнозам GSMA Intelligence количество соединений 5G в России достигнет 46 млн. к 2025 году, что составит 20 процентов от общего числа подключений. Исходя из этого, Россия превысит показатели среднемирового уровня, но все-таки не сможет перегнать Китай, США и Южную Корею на рынке 5G.
2) Терминалы оплаты
Согласно исследованию компании Juniper Research к 2022 году глобальное использование мобильных платежей увеличится на 28% из-за растущей популярности мобильных кошельков и онлайн платежей через приложения.
В 2019 году рынок POS-терминалов с поддержкой NFC показывал уверенный рост, где ежегодные мировые поставки достигали 47,8 млн. устройств. Сегодня производители ПО для POS-терминалов привлекают партнеров, для интеграции своих продуктов со сторонними платформами и увеличения базы пользователей.
Еще одна рекомендация специалистов для вендоров — интеграция облачных сервисов с платформой электронной коммерции. Благодаря такому решению ритейлеры смогут использовать преимущества этих омникальных решений.
Европейская финтех-компания MyPoS может превратить Android-смартфоны в PoS-терминалы для небольших предприятий розничной торговли. Бизнесы теперь могут принимать платежи по картам прямо на своих телефонах Android с помощью программного обеспечения PoS MyPoS Glass. Мобильное приложение позволяет совершать платежи с помощью бесконтактных карт и смарт-аксессуаров прямо на мобильном телефоне Android.
Принятые платежи сразу же переводятся на счет бесплатных электронных денег продавца благодаря функции мгновенных расчетов, которую MyPoS предлагает без дополнительных затрат для своих клиентов.
Источник: mypos.eu/en/glass
3) М2М в сельском хозяйстве
Технология M2M не только создает умные города будущего, но и производит революцию в сельскохозяйственном секторе. К 2050 году численность населения мира достигнет 9,6 миллиарда и “умные” методы ведения сельского хозяйства позволят нам прокормить постоянно растущее городское население, а к концу этого года интеллектуальное сельское хозяйство станет отраслью с оборотом 23 миллиона евро.
Технология M2M позволяет фермерам обеспечивать максимальную урожайность при минимальных ресурсах. Как? Датчики могут удаленно контролировать полевые условия, отслеживая данные по освещению, температуре и качеству почвы. А вот еще несколько примеров от компании Sierra Wireless, которые используются уже сегодня: