Русский
Русский
English
Статистика
Реклама

Управление проектами

Jekyll на VPS за 30 рублей для состоятельных людей

11.09.2020 16:15:38 | Автор: admin

Статический HTML почти ушел в прошлое. Теперь сайты это собой связанные с базами данных приложения, которые динамически формируют ответ на пользовательские запросы. Однако, в этом есть и свои недостатки: более высокие требования к вычислительным ресурсам и многочисленные уязвимости в CMS. Сегодня мы расскажем о том, как поднять свой простенький блог на Jekyll генераторе статических сайтов, контент которых берется прямиком из GitHub.

Шаг 1. Хостинг: берем самый дешевый на рынке


Для статических сайтов хватит недорогого виртуального хостинга. Контент при этом будет генерироваться на стороне: на локальной машине или, сразу с помощью хостинга GitHub Pages, если пользователю нужна система контроля версий. Последний, к слову, для создания страниц запускает все тот же Jekyll, но возможности конфигурирования программы вручную сильно ограничены. VPS намного интереснее виртуального хостинга, но стоит он немного дороже.

Сегодня мы в RUVDS снова открываем тариф ПРОМО за 30 рублей, позволяющий арендовать виртуальную машину на Debian, Ubuntu или CentOS. На тарифе есть ограничения, но за смешные деньги вы получите одно вычислительное ядро, 512 МБ оперативной памяти, SSD на 10 ГБ, 1 IP и возможность запуска любых приложений.

Давайте на нем и развернем наш Jekyll-блог.



После запуска VPS на него надо зайти по SSH и настроить необходимое ПО: веб-сервер, сервер FTP, почтовый сервер и т.д. При этом пользователю не придется устанавливать Jekyll на собственном компьютере или терпеть ограничения хостинга GitHub Pages, хотя исходники сайта можно держать в репозитории GitHub.

Шаг 2. Установка Jekyll


Если коротко, Jekyll это простой генератор статических сайтов, который изначально был разработан для создания блогов и последующего их размещения на GitHub Pages. Идея состоит в разделении контента и его оформления с использованием системы шаблонов Liquid: каталог с текстовыми файлами в формате Markdown или Textile обрабатывается конвертером и рендерером Liquid, а на выходе получается набор объединенных ссылками страниц HTML. Разместить их можно на любом сервере, для этого не потребуется CMS или доступ к СУБД все просто и безопасно.

Поскольку Jekyll представляет собой пакет (гем) Ruby, инсталлировать его несложно. Для этого в системе должен быть установлен Ruby версии не ниже 2.5.0, RubyGems, GCC и Make:

gem install bundler jekyll # 

При необходимости используйте sudo.

Как видите, все очень просто.

Шаг 3. Создание блога


Чтобы создать новый сайт в подкаталоге ./mysite, нужно выполнить команду:

jekyll new mysite

Перейдем в него и посмотрим содержимое

cd mysitels -l




В составе Jekyll есть собственный сервер, запустить который можно следующей командой:

bundle exec jekyll serve

Он отслеживает изменения контента и слушает порт 4000 на localhost (http://localhost:4000/) этот вариант может пригодиться, если Jekyll развернут на локальной машине.



В нашем случае стоит сгенерировать сайт и настроить веб-сервер для его просмотра (или выложить файлы на сторонний хостинг):

jekyll build

Созданные файлы находятся в подкаталоге _site каталога mysite.



Мы рассказали далеко не обо всех премудростях Jekyll. Благодаря возможностям верстки кода с подсветкой синтаксиса, больше всего этот генератор контента подходит для создания блогов разработчиков, однако на основе доступных в сети шаблонов с его помощью можно создавать самые разные статические сайты. Есть для Jekyll и плагины, которые позволяют изменить сам процесс генерации HTML. Если нужен контроль версий, файлы с контентом можно разместить в репозитории на GitHub (тогда на VPS придется установить Git).

Самое главное, что для этого пользователю не потребуются дорогостоящие тарифы. Все будет работать даже на той самой 30-рублевой VPS.



Подробнее..

Как я собирал статистику по брутфорсу наших серверов и лечил их

21.09.2020 14:20:44 | Автор: admin

Мы разместили 5 ханипотов, в дальнейшем просто серверов, чтобы собрать статистику по брутфорсу RDP в наших сетях.

Один сервер находился в Лондоне, другой в Цюрихе, один в защищенной сети в M9, два других в дата-центре Rucloud в защищенной и незащищенной сетях. IP адреса каждого из серверов находятся в разных подсетях, каждый IP адрес отличается первым октетом. Если попытаться измерить расстояние скана между IP адресами по формуле:

((Первый октет подсети 1) (Первый октет подсети 2)) * (2^24),

Если сканировать 0.0.0.0/0, атакующему придется пролистать как минимум 771751936 IP адресов, чтобы найти два самых ближайших друг к другу сервера. Вдобавок, каждый из серверов не отвечал на ICMP и каждый IP адрес не использовался никем в течение 3 месяцев, все 5 серверов открыли порты в одно и то же время. Все серверы были подключены к AD.

Разноцветные графики


Начинаем с интересного и заканчиваем значительным.



Начало было хорошим. Первый брутфорсер сел на сервер в Rucloud в первый же час, как порт был открыт. На всех остальных дата-центрах сервер был обнаружен только на второй час.

Как видно на графиках, сила перебора не сильно менялась изо дня в день. А если посмотреть по времени суток? Вот графики. Разные цвета это разные сутки.


График по времени суток дц ZUR1.


График по времени суток в защищенной подсети M9.


График по времени суток в дц LD8.


График по времени суток в защищенной подсети Rucloud.


График по времени суток в Rucloud.

Достаточно скучная картина, можно сказать, что картина не меняется в зависимости от времени суток.

Посмотрим на эти же графики по времени суток, но уже суммарно по всем дата-центрам.


График по времени суток с накоплением.


График по времени суток.

Картина с перебором паролей не меняется в зависимости от времени суток. То есть, устройства, которые участвовали в переборе паролей, скорее всего, всегда включены.


Статистика неудачных попыток входа по каждому адресу по одной незащищенной подсети Rucloud.

Всего, в переборе за целую неделю на одной из незащищенных подсетей Rucloud поучаствовали 89 IP адресов. 10 IP адресов набили 50% из 114809 попыток.


Статистика неудачных попыток входа по каждому адресу по всем дата-центрам.

Этот же самый блин, но только со статистикой по всем дата-центрам. 50% всей статистики набили 15 IP адресов. Попыток по всем пяти серверам было более полумиллиона. А насколько разными были атакующие?



По всем сетям было замечено 143 IP адресов и лишь 29 IP адресов было замечено на всех 5 серверах. Меньше половины из всех атакующих брутили 2 или более сервера. Значит, расстояние сканирования между IP адресами имеет значение. Значит, данные об открытых портах атакующие получали с помощью nmap, сканируя IP адреса один за другим.

Считаем ботнеты


Посмотрев на отчеты и юзернеймы, которые использовались для перебора, мне бросились в глаза словари, которые использовали разные IP адреса, количество логинов в словарях.

Предположим, что это все разные ботнеты с разными словарями, тогда, я насчитал N ботнетов. Вот словари каждого из них:

admin, administrator, administrador, administrateur, admin, administrator, administrador, administrateur, ADMIN, USER, USER1, TEST, TEST1, ADMINISTRATOR, USER1, USER2, USER3, USER4, USER5, USER6, USER7, USER8, USER9, HP, ADMIN, USER, PC, DENTAL

Этот ботнет был самым большим и использовал самый большой словарь. Там встречались много логинов на разных языках, в т.ч. русский, французский и английский:

1, 12, 123, 1234, 12345, 13, 14, 15, 19, 1C, CAMERA, СAMERA, ADMIN, USERL8, GVC, ADMINISTRATEUR, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADM, ALYSSA, ADMINISTRATOR, ATELIER, CAMERA, СAMERA, ADMIN, USERL8, GVC, ADMINISTRATEUR, USR_TERMINAL, JEREMY, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADMIN, ADM, SERGEY, OLEG, IRINA, NATASHA, SYSTEM, SERVICE, GVC, ADMINISTRATEUR, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADMIN, ADM, SERGEY, OLEG, IRINA, NATASHA и так далее, включая даже китайские логины.

Были словари, которые использовали только китайские и английские слова. Вынуть китайские символы из базы с помощью Powershell мне не удалось. Вот только часть словаря китайских товарищей:

SHENZHEN, TIANJIN, MANDARIN, CHONGQING, SHENYANG, XIAN, CONS, CHINA, TECHNOLOGY, ISPADMIN, BEIJING, SHANGHAI

Так же были единичные IP адреса пытающиеся перебирать эти логины. Вероятно, просто дети играются:

USR1CV8, ADMINISTRATOR
ADMI, NIMDA, ADMS, ADMINS

Бывает просто тупой перебор паролей, перебор паролей по словарю, а есть более-менее интересный перебор. У атакующих есть возможность получить имена пользователей, SMB шар, иногда даже хэши паролей, имена компьютеров, имя домена AD или WorkGroup.

Специалисты по ИБ знают о BloodHound, о ней знаю и хакеры. Если мы оставим AD в дефолтном её состоянии, то можно похитить имя домена, имя компьютера, даже хэши паролей юзеров. На хабре уже писали о векторах атаки на AD и об этой тулзе. Я рекоменду к прочтению этот блестящий материал.

Кстати, первая атака с применением имени сервера и домена началась через 13 часов после открытия портов, но взломщик быстро отстал, попытавшись ворваться всего 138 раз. Вторая такая атака с этим же словарем повторилась через 3 дня, но тоже долго не продлилась.

Итого 5 ботнетов с разными словарями. Надо будет собирать более подробную статистику по используемым логинам, чтобы понять, какие чаще всего используются и в каких пропорциях. Весьма вероятно, что первый взгляд замылен не слишком точным сбором всей статистики и реальная картина немного интереснее.

А это проблема?


Сначала самоизоляции мы начали фиксировать очень странную недоступность серверов. Сначала мы списали все это на перегрузку сети провайдеров домашнего интернета, на Netflix и торренты, бывает, инфраструктура была не готова.

Подозрения на инфраструктуру быстро исчезли, когда наши немногочисленные клиенты на Windows Server 2008, те не могли зайти на RDP в принципе. Посмотрев в журнал безопасности, мы фиксировали рекордные показатели атак, более 36 тысяч попыток за 24 часа.

Как оказалось, брутфорс достаточной интенсивности способен либо целиком положить RDP, либо вызывать постоянные разрывы.

Генез проблемы до конца неясен. Либо RDP кладется всей сворой, либо каким-то одним атакующим. Воспроизвести дисконнекты и зависание картинки с помощью скрипта и mstsc.exe не удалось.

То ли брутфорс превращается в DDoS, толи у какого-то из атакующих как-то по-особому реализована брутилка, что вызывает и проблемы. Единственное что ясно, что время разрыва соединение совпадает с неудачными попытками входа в систему.

Самые зверские атаки проходили этим летом в июне, тогда наша поддержка фиксировала наибольшее количество лагов и разрывов RDP. К сожалению, мы тогда еще не собирали статистику.


Источник: Kaspersky

Решение?


Да.
Все что нужно сделать чтобы защититься, это закрыться брандмауэром. Но я ощущаю ту же самую лень, что и вы, поэтому сделал эти модули.

Модули работают на Windows Powershell 5.1 и Powershell Core 7. Ссылка на гитхаб проекта находится тут. Теперь взглянем на функции.

Protect-Bruteforce


Пока что модуль называется так. Изменяет правило брандмауэра, добавляя все успешно залогиненые IP адреса в правило. Удобно для использования вместе со статическим IP адресом, упрощает деплой серверов удаленных рабочих столов в связке с VPN шлюзом.



Unprotect-Bruteforce


Сбрасывает RemoteAddress для дефолтных правил брандмауэра.



Stop-Bruteforce


Просматривает журнал событий на предмет неудачных входов и блокирует IP адреса из списка отдельным правилом Stop-Bruteforce.



Get-Bruteforce


Возвращает массив объектов статистики по каждому IP адресу. Именно этой функцией собиралась статистика для графиков выше.



Опрос


Мы в RUVDS считаем, что операционная система должна доставляться пользователю в предельно неизмененном состоянии. Мы думаем, что в идеальном мире, операционная система должна предоставляться так, какой она была в своем стоковом состоянии при первом запуске. Но ведь функции, такие как генерация паролей из ЛК, не только упрощают жизнь, просто необходимы многим нашим клиентам. Хотим знать ваше мнение о подобного рода quality of life штуках. Голосуйте и комментируйте.




Подробнее..

Однодневный спринт реальность или вымысел?

10.09.2020 10:11:09 | Автор: admin

Зная, как я люблю экспериментировать, иногда на конференциях меня коллеги спрашивают: "Ну, какой у тебя теперь минимальный спринт?"


Я и сам сейчас задумался с этой самоизоляцией и работой на дому да на даче, какой у меня реальной длительности спринт.


И с удивлением понял: один день.



Думаете, такого не бывает, что это из разряда жар-птицы, единорога и серебряной пули. А я вам покажу, как бывает.


Честно, то, что я однодневными спринтами иду, я спринтами их не называю, но планирую свой завтрашний день, свой завтрашний спринт. Современный мир настолько быстро меняется, что неделя это такая вещь, которая устаревает очень быстро. Хорошо получается запланировать только один день, а остальные дни нужно постоянно накануне перепланировать, что-то вносить новое в спринт. Поэтому однодневные спринты в современном мире мне кажется, будут оптимальными.


Считайте, что это первый важный фактор человека, который в условиях кризиса желает удержаться не только на своём месте, но и улучшить навыки, усилить себя и команду. Скажете: и так все на пределе. Если работать по старым методологиям, по старым сценариям, то да, выгоришь быстро. И месяца не пройдёт.


Соответственно, второй, немаловажный фактор навык современного человека, который хочет благополучия карьерного и финансового, это уметь взаимодействовать с другими людьми, объединяться в команды со схожими интересами, заражать, возможно, людей своими идеями, целями и интересами, объединяться с ними для достижения каких-то общих целей.


Потому что один человек мало, что может достичь. Ему всегда нужен кто-то, кто с ним будет проходить этот путь. Хотите, называйте это адептами, последователями, командой, неважно, в какой конфигурации. То есть, это не процесс эксплуатации одного человека другим. Это процесс открытого взаимодействия, открытого создания группы людей, формирования каких-то целей, открытости и прозрачности для достижения этих целей, то есть. Когда все члены команды понимают, что они достигают эту цель, то это, по сути, опять тот же Scrum. На таких принципах он и строится.


Мы провели курс для Scrum-мастеров Профессия SCRUM-мастер. И уже можем поделиться результатами с него и наблюдениями.


N.B. редактора: Это не рекламная и не продающая статья. Курс уже прошёл. В этой статье никто и ничего не предлагает купить, подписаться, зарегистрироваться. Просто обдумать то, что получилось, какие инсайты пришли за время процесса.

Сейчас эксперты разной степени надутости щёк пророчат долгую экономическую рецессию и рост безработицы в мире после пандемии. И естественно, что у IT-специалистов, как опытных, так и начинающих и студентов, возникает вопрос, какие качества и навыки нужно в себе развивать, чтобы оказаться среди тех, кто будет демонстрировать финансовый и карьерный рост?


И это хороший вопрос. Как раз в рамках прошедшего курса. Давайте попробуем сформулировать.


Конечно же, даже после пандемии, мир продолжит быстро меняться. Много неопределенностей в этом мире нужно быстро соображать, что происходит, быстро включаться в процессы, соответственно, здесь нужны люди, которые умеют гибко мыслить, умеют быстро воспринимать информацию от окружающей действительности, принимать её.


Потому что многие люди, к сожалению, получив обратную связь от действительности, приходят к мысли о том, что проблема с действительностью. То есть, если бы действительность была вокруг другая, я бы был другим.


Это очень большое заблуждение, и это один из больших блоков, которые не позволяют тебе развиваться, потому что, пока ты считаешь, что вокруг все виноваты, а один ты молодец, тогда ты себе отлично ответишь на вопрос, зачем мне не надо развиваться, зачем мне, вместо того, чтобы вечером читать книжку, лучше посмотреть телевизор и сказать, что виноваты все вокруг.


Поэтому очень важно уметь не только видеть информацию, которую до тебя доносит мир и причём доносит до тебя регулярно, и регулярно её запрашивает в окружающем мире, ну и воспринимать адекватно с тем намерением, чтобы самому для себя принимать решение, куда же тебе развиваться дальше, как тебе развиваться дальше, то есть, по сути, постоянно этот фидбэк-клуб, это петля обратной связи с окружающей действительностью. Чтобы её постоянно воспринимать, нужно иметь тот самый гибкий мозг, который воспринимает эту информацию, который умеет гибко подстраиваться, гибко строить планы относительно того, что же мы делаем дальше, исходя из той информации, которую ты только что получил. По сути, непрерывная проверка гипотез онлайн, даже на уровне интуиции.


Это, наверное, и есть Scrum личного характера, саморазвитие, один из спринтов, который вы выберете сами для себя. А мы знаем случаи, когда люди используют спринты и каждый день анализируют себя, что было сделано хорошо, что можно было сделать лучше, где надо улучшаться. И это делают каждый день и это же двигает их дело семимильными шагами по карьере, по финансовому благополучию.


У меня есть убеждение, что люди с таким гибким майнсетом будут развиваться в любой кризис, не только в этот, ну и в любой другой. По сути, эмолюционный принцип кто быстрее приспосабливается к изменяющимся условиям, тот выигрывает, избегает хищников, оставляет потомство, находит безопасные биогеоценозы для жизни, в конце концов встаёт с четырёх лап на две ноги, а в одну из рук берёт палку-копалку.


Но есть и опасность переусердствовать. Многие сейчас ринулись в Аgile, как будто пандемия их подтолкнула и не только начали трансформацию снизу-вверх, или там слева-направо, а совсем не сверху-вниз, как и должно быть. Не изменятся топы, дела не будет. Будет чистый карго-культ.


Если вы прочитаете книжку про Билла Гейтса и узнаете, что он встает в 6:00 утра и вы почему-то решили, что он поэтому миллиардер. Если встать в 6:00 утра, то вы миллиардером не станете примерно никогда. То, это как раз такое классическое применение карго-культа. А Scrum или Agile, поскольку он имеет большое количество церемоний, хорошо прописанных в Scrum-гайд там очень легко описанные методологии и задачи пробовать скопировать. И получить из всего этого реальный Agile карго-культ очень легко. Скорее он с большей вероятностью у вас получится, чем реально действующий Agile. Попытаться тупо и без огонька, без трансформации "сверху-вниз", от топов к линейным сотрудникам, просто как написано в Scrum Guide, в надежде, что у вас случился Scrum, попросту бесполезно.


Надо разобраться с основами этого процесса, с основами этого явления. То есть, пока вы пытаетесь скопировать слона по той части, которую вы трогаете, у вас своего слона не получится сделать. То есть, потрогали за хобот, хобот это какая-то труба, давайте соберем трубу, у нас будет слон.


Необходимо посмотреть на это явление с разных сторон, вникнуть в суть этого явления, возможно, посмотреть, как это явление или процесс реализован в других успешных уже компаниях, организациях или командах, и начинать, на самом деле, с основ, потому что это тот же Scrum, он, с точки зрения процессов, работает всегда поверх изменённого сознания.


Когда в сознании в правильном направлении построены все ценности, все эти практики и мероприятия появятся естественным путем. Потому что, примерно так они и появились в своё время. Потому что люди поменяли свое сознание, сделали клиента центром своей Вселенной, а не наоборот и всё начало крутиться вокруг него, и начали появляться те мероприятия, процессы, которые способствовали появлению Agile и Scrum. Это как раз к извечному вопросу: Что появилось первым курица или яйцо. Само клиентоцентричное отношение или Agile.


По большому счёту, когда Scrum только зарождался, и он не был ещё мейнстримом, многие компании и команды к этому пришли интуитивно. Просто они поменяли себе мышление, поставили в центр Вселенной своих клиентов, и пришли к тому, что, оказывается, клиенту нужно довольно часто показывать то, что ты делаешь.


Оказывается, для того, чтобы обрабатывать то, что говорит клиент, необходимо планировать задачи в течение какого-то срока. Чтобы эти задачи в течение какого-то срока не пытался кто-то изменить, надо значит закрыться каким-то определением, под названием итерация, которое стало потом спринтом, достаточно коротким, для того, чтобы регулярно показывать клиенту какую-то ценность, спрашивать его отзыв, фидбэк, и опять же вырабатывать следующий спринт.


А, для того, чтобы этот фидбэк от клиента в команду вносил максимальную ценность, должен быть не один человек, который принимает решение о том, что должно быть сделано, и как должно быть сделано, а этим должна заниматься команда. И пропала необходимость в Project-менеджере.


Таким вот образом это всё просто эволюционно образовалось. Были компании, которые дошли до Scrum своим собственным опытом. И оказалось, что у них получился Scrum, когда Scrum стал мейнстримом. Поэтому Scrum это такая естественная штука, когда ты немножко меняешь свой мейнстрим, в основе которого лежит понятие, что ты вокруг клиента крутишься, а не наоборот.
И он, естественным образом, сам у вас и образуется. Поэтому, если начинать с копирования мероприятий, то, скорее всего, вы в карго-культ и свалитесь. А вот когда изменится мышление в компании от топов для команд разработчиков вы сами свалитесь в Scrum.


Секретом Полишинеля по спринту длиной в 1 день поделился Алексей Куксёнок, Руководитель проектов в компании DataArt, входящей в Inc. 500 I 5000 (самые быстрорастущие компании США), в список 1000 компаний вдохновляющих Британию. Участвовал в нескольких десятках проектов с численностью сотрудников от 2 до 60 человек, реализованных, как и с использованием гибких методологий (Scrum, Kanban), так предиктивных (PMI-PmBoK).

Подробнее..

Recovery mode Интернет-магазин как черная дыра в бюджете

07.09.2020 00:18:29 | Автор: admin

Тема затрат на интернет-бизнес актуальна как никогда. Особенно в период когда все переходят на удалёнку. Давайте вместе посчитаем, во сколько же нам обойдется владение и содержание одного года работы полноценного интерне-магазина.

Я понимаю, что решения для экономии денежных средств, используют многие. Главными проблемами этих решения является безопасность и законность внедрения. Всему виной закон о персональных данных. Они вводятся, когда покупатель оформляет заказ.

Споров на эту тему много. Я хочу привести пример, когда все учтено и не спорно, с юридической точки зрения.

Если Вы действующий предприниматель и думаете над открытием интернет-торговли, данная статья поможет провести расчеты, проанализировать какие ресурсы уже имеются у фирмы, и какие в будущем предстоят затраты.

Программное обеспечение

Интернет-магазин, это не одна программа. Это сложный программно-аппаратный комплекс. Бесплатное программное обеспечение я не рассматриваю, по ниже перечисленным причинам:

  1. Отсутствие сертификации ФСТЭК России. Мы обрабатываем персональные данные, и в данном случае программы с открытым кодом и множеством уязвимостей, использовать не имеем права.

  2. Сложность в реализации проекта. Никто не гарантирует, что все будет работать из коробки. Все нужно настраивать, "прикручивать" и "допиливать". Либо это постоянная работа, либо постоянные затраты.

  3. Поломки при обновлениях. Совсем не обновляться нельзя. А обновившись, Вы получите новый букет проблем с функционалом, в котором разберется как минимум верстальщик.

  4. Сложности в подключении к официальным серверами и интеграцией с программами.

  5. Отсутствие гарантированной и квалифицированной поддержки разработчиков.

  6. Отсутствие нормальной документации для разработчиков и пользователей. Решение некоторых проблем можно найти только на англоязычных ресурсах.

Рассмотрим нашу задачу с использованием СMS для управления сайтом "1С-Битрикс". Это не реклама, прошу учесть, а пример.

Когда мы говорим о работе фирмы, в первую очередь встает вопрос учета. Торговля это не только сайт, но и бухгалтерия, склад, счета и налоги. А у большинства бухгалтеров стоит "1С-Управление Торговлей". Логически выбрать программу для интернет-магазина, тех же разработчиков, что и бухгалтерского программного обеспечения. Самая актуализированная с точки зрения законодательства - это "1С-Битрикс". Сертификат ФСТЭК России имеется.

Стоимость на дату написания статьи:

Редакции 1С-Битрикс: Управление сайтом редакция "Малый бизнес"- 35 900 рублей;

Учтем в расчетах стоимость программы "1С-Управление Торговлей" - 27 300 рублей;

Так же посчитаем стоимость программ которые либо уже установлены на компьютере, либо их придется приобрести:

  1. Операционная система Microsoft Windows 10 Professional 32/64 bit SP2 Rus Only USB RS (HAV-00105) - 13 490 рублей;

  2. Офисное приложение Microsoft Office для дома и бизнеса 2019 - 18 790 рублей;

  3. Антивирус KASPERSKY Internet Security Multi-Device 1 устр 1 год Новая лицензия Card - 1 800 рублей.

  4. Межсетевой экран ИКС ФСТЭК - 52 180 рублей.

На этом месте хочу остановиться. Требуется не только межсетевой экран, но и контроль приложений (DPI), контентная фильтрация, авторизация пользователей и фильтрация почтового трафика. Проще подобрать какое то комплексное решение, имеющее необходимый сертификат и набор приложений. Для этого нужно либо отвести отдельный комп под шлюз, либо приобрести программно аппаратный комплекс целиком. Для простоты учета готовый, собранный разработчиками.
Вот тут как настроить.

Хостинг, домен, SSH

Теперь немного о сервере, на котором будет установлен сайт. Часто все покупают хостинг. Но! А как же защита базы данных? Битрикс использует разные, но самая популярная для этих целей все же MySQL. SQL инъекция это один из самых доступных и способов взлома сайта. И эту уязвимость нужно закрыть, если мы обрабатываем персональные данные.

Лучшим решением будет Облако с соблюдением ФЗ 152 УЗ4.

В документации "1С-Битрикс" указана фирма DataFort. Вот официальный сайт компании.

Мне как-то приходилось запрашивать у них прайс, и обсуждать этот вопрос, вот расценки и перечень необходимых для соблюдения законодательства элементы защиты системы:

  1. Ежемесячно, вычислительные ресурсы и дисковая подсистема, гипервизор Vmware - 6 800 рублей в месяц;

  2. Единовременно - средства защиты информации для УЗ-4 - 2 750 рублей;

  3. Ежемесячно - средства защиты информации для УЗ-4 - 1 102 рубля;

  4. Единовременно - ПО по подписке, виртуальный маршрутизатор до 500 Мбит/с - 9 304 рублей;

  5. Ежемесячно - ПО по подписке, виртуальный маршрутизатор до 500 Мбит/с - 3 814 рублей.

Так же нам нужен домен, наш адрес. Конечно, можно купить дорогой и красивый. Но наша цель - работающий вариант. А так как это может быть любой домен в любой зоне, больше тысячи рублей закладывать в расходы не станем.

Домен - 1 000 рублей.

Посчитаем SSL-сертификат, оннужен для того, чтобы мошенники не могли перехватить личные данные, которые пользователи вводят у вас на сайте. Я сотрудничаю с компанией рег.ру, цены можно посмотреть здесь https://www.reg.ru/ssl-certificate/

SSL-сертификат DomainSSL начального уровня на один год - 3 299 рублей.

Оборудование

Ноутбук или ПК - 25 000 рублей;

Роутер илимаршрутизатор - 5 000 рублей;

Мобильный телефон - 10 000 рублей.

Цены конечно ориентировочные. Какой выбрать компьютер или телефон, нужно решать конкретно каждому руководите исходя из бюджета. Слишком бюджетную технику ставить нельзя, так как комплекс программ не слабенький. Так же под задачи интернет-торговли часто приходится отрабатывать изображения, видео. Мощность процессора и объем памяти имеет большое значение.

Фирма - ООО или ИП

Затраты на регистрацию ИП (индивидуальный предприниматель) обычно минимальны только в том случае, когда все делает он сам. Самостоятельно заполнил форму и лично зарегистрировался. В данном случае нужно лишь открыть счет в обслуживающем банке и изготовить печать для документации.

Только не каждый вид деятельности можно вести на ИП. Другими словами, в зависимости от того, чем вы решили торговать, выбирают ИП регистрировать или ООО. Приведу в пример стоимость регистрации Общества с ограниченной ответственностью, для полноты информации.

  1. Юридическое сопровождение, изготовление уставных документов - 10 000 рублей. Стоимость ориентировочная, исходя из собственной практики.

  2. Услуги нотариуса - 2000 рублей;

  3. Изготовление круглой печати - 1 000 рублей;

  4. Открытие счета в банке, оформление карточки подписи - 3 500 рублей;

  5. Уставной капитал (нужно положить на счет при открытии) - 10 000 рублей

  6. Цифровая подпись для сдачи отчетности - 1 500 рублей;

  7. Программное обеспечение для сдачи отчетности 6 000 рублей;

  8. Аренда офиса - 10 000 рублей.

Кассовый аппарат

Не секрет, что практически любая торговля не возможна без кассового аппарата. В случае с интернет-магазином, у вас он может быть как и физический, так и виртуальный. Ведущие производители кассовых аппаратов сейчас предлагают подключение вашего интернет-магазина к виртуальной кассе. Удобно это? Конечно удобно! Ломаться нечему! Обслуживать нечего! Сейчас, кто работал в торговле, хорошо меня поймут. Ничего не заедает, лента не заканчивается! Вообщем, отпадает большое количество разного рода проблем с техническим устройством.

Стоимость АТОЛ Онлайн - 34 800 рублей.

Конечно, вы можете приобрести физический кассовый аппарат. В этом случае его устанавливают в офисе, подключают какой то платежный агрегатор например ЯндексКасса и при зачислении денежных средств от покупателя на расчетный счет фирмы, выбивается чек и отправляется вместе с товаром или на электронную почту. в этом случае затраты будет на 10-15 тысяч меньше, а вот проблем и работы больше.

Работник - ответственное лицо, администратор

Не важно, сами вы будете вести свой магазин или наймете работника, страховые взносы платить придется.

Взносы ИПза себя в2020году в ПФР составляют 32 448 рублей.

В случае с работником, прибавим к этой сумме минимальную оплату труда, так же за год.

Федеральный МРОТ с 1 января2020года равен 12 130 рублям - ежемесячно. За год выплатить необходимо 145 560 рублей. Если конечно МРОТ не изменится)

Сторонние услуги или несколько вопросов по существу

  • Кто будет устанавливать, настраивать и обслуживать программное обеспечение и технические средства;

  • Кто подготовит документы на регистрацию фирмы;

  • Кто ведет бухгалтерию и внутреннюю документацию;

  • Будут ли изменения дизайна, нужны ли услуги дизайнера и верстальщика;

  • Кто подготовит документацию по защите информации;

Заключение

Посчитаем сколько получилось? Примерно 521 613 рублей. Кто будет соблюдать все эти правила? А главное оплачивать. Скорее всего НИКТО. А ведь многое я не учла, да и бывают непредвиденные траты.

Так же мной не учтены траты на обучение. Руководителю нужно обучается по защите труда и пожарной безопасности, раз в пять лет. Учиться и сдавать экзамены придется, если на фирме есть наемные работники. Так же нужно выполнить аттестацию рабочих мест. Работник ответственный за обработку ПД, так же должен пройти соответствующее обучение.

Защита информации в нашей стране, из инженерной задачи превратилась в финансовую проблему. А законодательство, крайне агрессивно к малому бизнесу. Соблюдать все требования крайне затратно.

Приглашаю всех желающих и несогласных в комментарии. Буду рада конструктивной критике.

Подробнее..

Сказка как проект цели, планирование, оптимизация обучаем ребёнка навыку проектного мышления

27.09.2020 10:19:36 | Автор: admin
Внимание! В посте есть спойлеры к сказкам.

Что такое проектное мышление, зачем оно детям и причём тут детские сказки


Если начать отвечать на первый вопрос, то ответ на второй придёт сам собой.

Мне нравится такое определение для проектного мышления: это способность определять цель и шаги по её достижению с учётом имеющихся обстоятельств и ресурсов, навык, который актуален в любом возрасте, начиная с 6-ти летнего. (Ограничение в 6 лет связано с особенностями развития человеческого мозга до этого возраста у ребёнка ещё отсутствует волевая регуляция и способность к планированию.)

Ведь, если так подумать, практически вся наша жизнь это череда больших и маленьких проектов: организовать путешествие, сделать ремонт, распланировать семейный бюджет на месяц Даже поход в магазин за продуктами можно представить как проект. И для ребёнка это тоже актуально просто в детстве задачи стоят несколько другие. И поэтому я предлагаю начать обучать проектному мышлению, как только мозг для этого созреет. Сегодня я расскажу про игру по сказкам: будем развивать навык проектного мышления ребёнка с помощью самого доступного сборника упражнений книги сказок.

Как играть


Народные сказки это собрание самых разнообразных жизненных ситуаций, на которых мы и будем вместе с ребёнком оттачивать навык проектного мышления. Отсюда и это сборник упражнений: каждую из сказок мы будем рассматривать как отдельное упражнение на проектное управление.

Процесс игры можно строить по-разному, здесь я по большей части описываю последовательность основных шагов и даю инструкцию, как сделать и использовать игровое поле.

Для игры понадобятся сказка, лист бумаги (будет служить в качестве игрового поля), ручка/карандаш, цветные стикеры-закладки (будем использовать вместо игровых фишек). Суть игры сводится к простой последовательности шагов:

  1. Вместе с ребёнком читаем сказку, соответствующую возрасту ребёнка.

    I. Систематизируем информацию:
  2. Делим сказку на этапы (что такое этап в данном контексте и зачем он нужен, расскажу ниже) и на нашем листе оформляем этапы в таблицу, где название этапа заголовок столбца.
  3. Выписываем всех персонажей из первого этапа на стикеры (1 персонаж стикер) и вклеиваем их в первый столбец (первый этап нашей сказки).
    Начинаем играть:
  4. С помощью наводящих вопросов помогаем ребёнку определить цель главного героя на первом этапе (обычно цель главного героя в сказке очевидна), записываем в столбец с первым этапом.
  5. Помогаем ребёнку выделить обстоятельства, которые сопровождают героя на первом этапе, инструменты, которые у него есть в наличии (конь, лук, серебряное блюдце-золотое яблочко и т.д.), заносим в таблицу в первый этап. Можно для обозначения обстоятельств и инструментов использовать карточки с картинками или фигурки.

    II. Анализируем:
  6. Вместе с ребёнком пытаемся проанализировать цель героя: правильно ли она выбрана, что достижение данной цели даст главному герою. Вот ещё несколько вопросов, которые можно задать на этом шаге:
    Как думаешь, почему именно эта цель?
    Что даст герою выполнение этой цели?
    Какую цель выбрал(а) бы ты на месте героя?
    Чем герой мотивируется (или проще: почему он хочет этого?)
    Можно ли заменить эту цель другой? Какой?


    Если в процессе обсуждения был сделан вывод, что цель главным героем выбрана неверно, и её нужно заменить, вписываем в первый столбец новую цель.

    III. Генерируем идеи:
  7. Вместе с ребёнком генерируем идеи, как главному герою достигнуть поставленной цели с учётом существующих обстоятельств и доступных инструментов.
  8. Если цель на этом этапе достигнута или на этом этапе цель достигнуть не получается и требуется переход на следующий этап, переносим наши импровизированные фишки на следующий этап и повторяем все шаги на следующем этапе. Так играем до конца сказки или пока цель главного героя не будет достигнута.

Пример игрового поля для сказки Деревянный орёл:


Нюансы игры


Иногда у героев нет никаких целей ни в первом, ни даже во втором этапе (просто идёт перечисление событий), тогда просто фиксируем всю информацию об этапе и переходим с персонажами на следующий этап (переклеиваем стикеры в соседний столбец, переносим карточки/фигурки). Когда цель есть, не останавливайтесь после того, как ребёнок её определил провоцируйте ребёнка на обсуждение: вместе с ребёнком убедитесь, что цель выбрана правильно, поинтересуйтесь, почему, как думает ребёнок, персонаж выбрал именно эту цель и т.д. Полезно подвергать сомнению обоснованность цели в сказке. (Например, в сказке Г. Х. Андерсена Свинопас сам главный герой разочаровывается в своей первоначальной цели и в конце сказки от неё отказывается.)

В некоторых сказках можно выбрать персонажа, за которого можно играть.

Вариант игрового поля для сказки Вещий сон:

Первые два этапа просто повествование, перед персонажами не стоит целей, хотя, в процессе обсуждения ребёнок может предложить их сам. А вот на этапе У Елены можно сыграть за Елену, тем более, что по сюжету её попытки достигнуть цели оказались неудачными возможно, ребёнок сможет предложить лучшее решение.

Некоторые цели это настоящая загадка на логику, как, например, в сказке Чудесная рубашка: после того, как Змей Горыныч убил Ивана-купеческого сына, он надел его волшебную рубашку (а того, кто рубашку эту носит, никто осилить не может). И хотя Ивана потом оживили, явиться во двор ко Змею Горынычу, пока на Змее Горыныче эта рубашка, он уже не мог нужно было придумать способ, как снять с него рубашку, имея на руках перстень, который того, кто его наденет, в коня превращает.

Пример игрового поля для сказки Чудесная рубашка:


Зачем нужно деление на этапы


Сюжеты большинства сказок совершенно непредсказуемы: практически невозможно угадать, что будет в следующий момент, какие новые задачи встанут перед главным героем. И это то, почему сказки так хороши для тренировки фантазии и аналитических способностей ребёнка: сказка постоянно подбрасывает новые обстоятельства, и ребёнку нужно анализировать как достигнуть изначальной цели с учётом изменившихся обстоятельств.

Но с другой стороны, как планировать свои шаги, если ты знаешь, что уже в следующем абзаце всё поменяется, и твой план потеряет смысл?

Поэтому для того, чтобы ребенок мог сконцентрироваться на поставленной цели и текущих обстоятельствах, я предлагаю делить сказку на этапы.

В данном контексте этап это отрезок повествования, описывающий определённые обстоятельства, в которых герой решает конкретные задачи. И если целиком события в сказке не поддаются планированию, то в рамках одного этапа вполне комфортно придумывать шаги для достижения цели. Другой вопрос в том, что ресурсов, которые есть в рамках этапа, может быть недостаточно, и тогда можно перейти на следующий этап.

Бывает и наоборот: в процессе обсуждения оказывается, что в текущем этапе есть все инструменты, чтобы достигнуть конечной цели, но по сюжету главный герой этого как будто не замечает. Так, в сказке про Джека и бобовые зёрна, когда в начале сказки встаёт вопрос, а как прокормиться, главным героям Джеку и его маме приходит здравая мысль продать корову и на вырученные деньги организовать лавку. Но в момент, когда Джек стащил у людоеда мешок с золотом, они с мамой почему-то предпочитают их просто проесть, а потом опять наведаться к людоеду, чтобы украсть у него ещё что-нибудь.

В сказке Сказка о молодильных яблоках и живой воде царевич идёт пьянствовать, вместо того, чтобы вернуться домой, когда у него есть для этого все возможности (по пути ещё с собой всех пьяниц с округи собирает и тусует с ними 3 года).

Это, кстати, хороший момент, чтобы объяснить ребёнку, что такое оптимизация: мы достигли цели на данном этапе, а остальные действия можно было просто не совершать.

Несколько слов в заключение


Напрашивается закономерный вопрос: зачем что-то придумывать, если в сказке уже всё описано?

Во-первых, как было сказано выше, это отличное упражнение для тренировки системного мышления: в процессе игры ребёнок учится вычленять из всего потока информации необходимые данные (речь идёт о той части, где мы предлагаем ребёнку поместить на игровое поле цели, обстоятельства и инструменты).

Мы развиваем критическое мышление: ребёнок не просто читает сказку, он учится оценивать информацию, которую ему предлагают, задавать вопросы и предлагать лучшее решение. Он анализирует, как описанные обстоятельства влияют на героев, какие инструменты можно использовать для решения конкретных задач. К тому же это отличный способ развивать воображение.

Выше я сравниваю эту игру с упражнением, и как с любым упражнением, эффект от игры будет только после многократного повтора. Просто попробуйте взять сборник сказок и сыграть в них все.

Однако, есть и такие сказки, для которых такая игра не имеет смысла например, сказка Летучий корабль (не путать с мультфильмом): думать в этой сказке не над чем все решения там уже есть (хотя эту сказку можно использовать как упражнение найди соответствие: какого мужика для выполнение какого царского задания можно использовать). Поэтому я рекомендую взрослым заранее прочитать сказку и поделить её на этапы.

Очень важную роль играет способность взрослого задавать правильные вопросы. Вопросы в этой игре это основной инструмент взрослого, именно вопросы подталкивают ребёнка анализировать, придумывать что-то новое, делать выводы.
Ниже я предлагаю примерный список вопросов.

Обстоятельства:
Как герой может использовать его текущие обстоятельства?
Есть ли что-то, что ему мешает? Что можно с этим сделать?

Инструменты:
Как можно использовать данный инструмент помимо способа, предложенного в сказке?
Может, его можно обменять на что-то более подходящее? Продать?
Чем можно его заменить?
А что бы мы могли сделать, если бы его не было?
Какой другой инструмент можно было бы использовать в этой ситуации?

Персонажи:
Чего он хочет? (Аналог Какая у него мотивация?)
Чего он боится?
Можно ли предложить ему что-то взамен (касается антагонистов)?
Почему ты считаешь, что он добрый (злой)?
Можно ли избежать конфликта? Как? Хотел(а) бы ты избежать конфликта?

Общие вопросы:
Как думаешь, твой вариант лучше, чем вариант в сказке? Почему?
Понравилось ли тебе играть в эту игру? Что понравилось? Что не понравилось? (ответы на эти вопросы помогут организовать игру наиболее интересным для ребёнка способом)
Какие персонажи тебе понравились? Почему?
Какие выводы мы можем сделать?


Это не исчерпывающий список вопросов, в процессе игры могут возникать и другие, главное, не забывать их озвучивать.

Обо мне
Привет! Меня зовут Марьям, последние несколько лет я занимаю должность проектного менеджера в ИТ. Я не понаслышке знаю, как круто использовать проектный подход в повседневной жизни, а в последнее время активно интересуюсь способами развития проектного мышления у детей младшего школьного возраста. Идея игры, описанной в этом посте, пришла в ответ на поиски доступного способа развивать у ребёнка проектное мышление в простой игровой форме.
Подробнее..

Исследования в сложных B2B-продуктах как это работает в Mail.ru для бизнеса

07.09.2020 20:15:27 | Автор: admin


Почта Mail.ru наш самый известный продукт и ценнейший актив к 2020 году сильно вырос. Сегодня это больше, чем просто почтовый сервис: в Почте можно отправлять и получать письма, организовывать свои планы на день, отслеживать штрафы и даже платить за ЖКХ.

У Почты появились не только новые функции, но и новые форматы. Важнейший из них B2B-сервис, который входит в платформу Mail.ru для бизнеса. Это Корпоративная Почта Mail.ru, которая экономит место на ваших серверах, интегрируется с популярными антивирусами и поддерживает совместный доступ к почтовому ящику и задачам.

Чтобы получались актуальные и удобные продукты, важно создавать их в контакте с пользователями, изучая их потребности, привычки и паттерны поведения. Поэтому процесс развития большинства направлений Mail.ru Group сопровождают usability-исследования.

Зачем нам usability-тестирование?


Пользу любых исследований можно обозначить так: на любом шаге развития продукта они помогают понять, насколько текущее направление работы соотносится с ожиданиями пользователей. Будь то этап идеи или развитие продукта после релиза. В процессе usability-исследований мы общаемся с реальными пользователями чтобы узнать, насколько понятно то, что мы уже сделали или собираемся сделать.

Получить подробные данные о привычках пользователей, их путях взаимодействия с продуктами и трудностях, с которыми они могут столкнуться, работа, которая требует больших ресурсов. Основные задачи наблюдать за тем, как пользователи справляются с интерфейсами продуктов или выяснять их потребности с помощью интервью или других методов. В Mail.ru Group этим занимается целая usability-лаборатория UXLab. Она растет так быстро, что даже за время работы над этой статьей может пополниться новыми сотрудниками. Это здорово, потому что желание развивать продукты, ориентируясь на потребности и привычки пользователей, говорит о стратегическом мышлении менеджмента и всей команды в целом.

Есть два основных пути, по которым usability-аналитик может работать с командами внутри компании. В первом варианте взаимодействие строится в формате внутреннего агентства: исследователь принимает запросы от разных проектов и попеременно работает с ними. Второй случай проект располагает собственным специалистом. Мы в UXLab Mail.ru Group перешли ко второму формату: сейчас каждый исследователь работает внутри определенной продуктовой команды.

Все продукты уникальны, поэтому для каждого отдельного случая подходит свой метод. Мы работаем преимущественно с качественными методами (интервью, фокус-группы, юзабилити-тестирования), но заходим и со стороны количественных данных. В особых случаях приходится применять особые методы. Сегодня речь именно о таком кейсе.

Особенности продуктов для бизнеса


У интерфейса продуктов Mail.ru для бизнеса есть два лица. Одно видит основная масса пользователей, которая использует продукты для бизнеса Почту, Мессенджер и Файловое хранилище в работе. Обычно это сотрудники компаний-партнеров, купившие наше коробочное решение. Второе видят те, кто настраивает и устанавливает пакет продуктов системные администраторы и технические специалисты. Они работают с GUI административной панели, где можно настраивать доступы, формировать группы пользователей и совершать другие действия, необходимые для нормального функционирования продуктов.



С интерфейсом самих продуктов сталкивается гораздо большее количество пользователей, чем с панелью администратора. Поэтому может появиться соблазн посвятить основные ресурсы улучшению той части, которую видят чаще. В случае с Mail.ru для бизнеса всё не так однозначно. Если системный администратор будет совершать ошибки из-за того, что мы плохо организовали административную панель, в конечном счете пострадают все сотрудники компании.

Для того чтобы избежать такого развития событий, в течение последнего полугода мы провели серию крупных исследований, посвященных технической части продукта. Исследовать административную часть продуктов Mail.ru для бизнеса сложнее, чем тестировать обычные пользовательские интерфейсы. Ниже я расскажу об особенностях тестирования технической части B2B-продуктов и о том, как мы справились вызовами этой области.

Почему непросто тестировать сложный B2B-продукт


  • Особый рекрутинг, непростые респонденты. Для исследований корпоративных продуктов Mail.ru мы ищем сотрудников потенциальных компаний-партнеров: как для тестирований технической стороны, так и для изучения самих продуктов. Таких респондентов системных администраторов, ассистентов руководителей находить сложнее: их время стоит дорого, поэтому и рекрутинг становится более затратным. Иначе нельзя: чтобы сделать вывод об удобстве продукта, нужно взаимодействовать именно с потенциальными пользователями.

  • Нестандартный интерфейс. В тестированиях инсталлятора и административной панели продуктов Mail.ru для бизнеса основная часть изучаемого интерфейса поля для заполнения, системы фильтрации и навигация внутри настроек. Помимо того, что это не самое часто встречаемое исследователями графическое наполнение, такие тестирования требуют особой техники проведения.



    Из-за особенностей программ для создания макетов интерфейса мы не можем позволить респонденту вводить любые данные в поля параметров при работе с прототипом. Выход из этой ситуации автоматическое заполнение данных по клику рандомными данными, которое мы заранее прописываем в инструменте для создания прототипа. Респондент видит пустые поля для заполнения, сначала рассказывает, что собирается внести в них, а потом кликает на строку и сравнивает свои ожидания с появившимся вариантом.

    Во время теста исследователь должен быть максимально сконцентрирован ему нужно внимательно отслеживать каждый шаг респондента, чтобы тот озвучил свои предположения до того, как случайно кликнет по одному из полей и увидит подсказку.
  • Специфический контекст происходящего. Обилие полей и настроек может запутать, но в их значениях разобраться еще сложнее. Системными параметрами продуктов не зря занимаются конкретные специалисты: чтобы хорошо понимать суть происходящего, нужно получить соответствующее образование. Исследователь, как правило, не имеющий специальных знаний, сталкивается с запутанной и неизвестной ему терминологией. Сокращения вроде AD, SSL и ВКС (видеоконференцсвязь), часто встречающиеся в параметрах инсталлятора, поначалу могут казаться иностранным языком.

    В нашем случае решением оказалась глубокая вовлеченность в процесс исследования дизайнера, продакт-менеджера и руководителя отдела разработки. Последний помогал как в проектировании прототипа, так и в процессе исследований, что позволяло сориентироваться в происходящем и оперативно задавать вопросы о непонятных частях интерфейса.
  • Тестирования помогают определиться с направлением дальнейшей работы над интерфейсом. В основном, когда заказчики приходят к команде usability-исследователей с запросом, в предполагаемом интерфейсе уже продуманы сценарии использования, которые кажутся команде подходящими. Когда мы имеем дело с распространенными функциями, нам легко предположить, что может быть понятно и привычно пользователю. Например, на большинстве сайтов вход в личный кабинет находится в правом верхнем углу, поэтому мы можем рассчитывать, что если последовать этому паттерну или незначительно от него отступить, то у юзера не возникнет проблем с пониманием того, где мы спрятали его профиль.

    В случае Mail.ru для бизнеса мы имеем дело с набором функций, которые не мелькают ежедневно перед глазами миллионов пользователей. Мы работаем с интерфейсом, который видит узкая аудитория системные администраторы и технические специалисты компаний. Более того, в основном внутри административных панелей и инсталляторов содержится конфиденциальная информация, из-за чего нельзя просто взять и подсмотреть, как сисадмины привыкли работать с такими интерфейсами.

    Это приводит к тому, что к началу тестирования настроек продуктов для бизнеса мы часто подходим с двумя или тремя вариантами структуры прототипа без каких-либо предпочтений между ними. Основным вопросом становится не то, какой из продуманных нами сценариев удобнее, а то, попали ли мы в логику поведения респондентов или нужно все переделывать.
  • Кстати, про переделывание. По причине того, что мы нередко начинаем нащупывать нужные нам реализации прямо в процессе первых тестирований, для корпоративных продуктов Mail.ru подошел формат RITE Rapid Iterative Test and Evaluation. По стандартному плану проекта с usability-тестированием принято провести общение со всеми респондентами и уже после вносить правки по агрегированным результатам. В случае RITE этот процесс делится на несколько этапов: мы проводим несколько тестов, потом берем перерыв на быстрые правки по уже полученным сведениям, и следующие респонденты выполняют задания на обновленном прототипе. В зависимости от каждой конкретной ситуации можно установить подходящее количество этапов.

Какие результаты получили и как их интерпретировали?


Что может дать сочетание непростой предметной области с методом исследования RITE? Расскажу на примере тестирования инсталлятора корпоративных продуктов Mail.ru для бизнеса. Это было первое исследование интерфейсов подобного рода в нашей команде, и эффективный подход мы сформировали прямо в процессе него.

План тестирования состоял из трех этапов:

  1. Сначала, чтобы исправить самые крупные и заметные ошибки, мы собрали обратную связь от наших коллег. Так мы смогли исправить самые явные интерфейсные проблемы, не тратя ресурсы на поиск внешних респондентов.
  2. На втором этапе мы провели тестирования с респондентами из компаний-партнеров, чтобы получить максимально широкий и независимый от привычек конкретной команды взгляд на наш инсталлятор.
  3. На финальном, третьем этапе, мы показывали прототип конкретным специалистам системным администраторам, которые имеют опыт интеграции похожих коробочных решений для корпоративного использования. Они помогли нам разобраться с самыми тонкими нюансами.

Мы хотели сделать инсталлятор таким, чтобы с помощью инструкции с ним мог разобраться любой сотрудник компании-заказчика. Для этого на первом и втором этапе мы пообщались не только с техническими специалистами, но и казуальными пользователями сотрудниками, которые не имеют опыта работы с корпоративным ПО и вообще далеки от технических вопросов (менеджеры, HR, бухгалтеры). Эти респонденты помогали нам разобраться с вопросами сугубо интерфейсного характера и понять, насколько прототип в текущей реализации понятен людям, далеким от системного администрирования.

После трех итераций тестирования мы модернизировали интерфейс согласно данным, которые получали после каждой из групп респондентов. Мы смогли проверить, насколько логично и удобно организованы переходы по шагам инсталляции, понятна ли суть полей и настроек. В итоге мы переименовали часть полей, чтобы технические специалисты однозначно понимали, что от них требуется. Кое-где добавили подсказки, а какие-то настройки и вовсе спрятали или убрали.



Со стороны сугубо интерфейсных вопросов мы поняли, например, что нужно переделать строку прогресса, чтобы она перестала казаться кликабельной вопреки нашей задумке, и поработали над отображением шага с проверкой введенных данных.



Помимо наглядного результата usability-тестирования инсталлятора значительного улучшения интерфейса, мы убедились в правильности выбранной нами логики установки продуктов. Респонденты понимали последовательность шагов в инсталляторе и соглашались с ней, а их впечатления от работы с прототипом были приятными.

Однако в исследованиях так бывает не всегда. В процессе следующего тестирования, изучая настройки групп в административной панели, мы уже на первом этапе выяснили, что логика, которая казалась нам естественной, не оказалась таковой для системных администраторов. Но это тоже важный результат, ведь главное понять, что делать дальше и проверить гипотезу, а не обязательно подтвердить ее.



Выводы


Мы всегда стремимся рассказывать о своей работе и показывать, как здорово выпускать продукт в мир с уверенностью, что он будет понятен и удобен пользователям. Этой статьей хочется показать, что даже сложные интерфейсы, исследование которых связано с определенными преградами и трудностями, можно успешно изучать.

Под любой проект можно подобрать подходящий метод, который даст ответы на актуальные вопросы и поможет проверить ваши гипотезы, даже если поначалу непонятно, как это сделать. И неважно, работаете вы с B2B- или B2C-продуктом, важно сделать его качественным. В этом как раз помогают регулярные исследования. Удобный и понятный интерфейс залог счастья клиента, что в долгосрочной перспективе превращается в счастливых пользователей и вашу прибыль.
Подробнее..

Одна кнопка, чтобы тестировать их всех. Как не упустить все интеграции из поля зрения

24.09.2020 12:15:14 | Автор: admin
Привет, Хабровчане! Мы Владимир Мясников и Владислав Егоров представители команды интеграционного тестирования Mir Plat.Form (АО НСПК). Сегодня мы расскажем про разработанный и развиваемый нами инструмент автоматизации, позволивший сократить рутину во внутренних процессах команды.

Предисловие


Платёжная экосистема Mir Plat.Form включает в себя несколько десятков систем, большинство из которых взаимодействуют между собой по различным протоколам и форматам. Мы, команда интеграционного тестирования, проверяем соответствие этих взаимодействий установленным требованиям.



На данный момент команда работает с 13 системами уровня mission и business critical. Mission critical системы обеспечивают выполнение Mir Plat.Form своих основных функций, обеспечивающих стабильность и непрерывность функционирования банковской карточной системы РФ. Системы уровня business critical отвечают за поддержку предоставляемых клиентам Mir Plat.form дополнительных сервисов, от которых зависит непосредственная операционная деятельность компании. Частота выкатывания релизов в ПРОД варьируется от раза в неделю до раза в квартал, всё зависит от системы и готовности участников к частоте обновлений. В общей сложности мы насчитали около 200 релизов, прошедших через нашу команду в прошлом году.

Простая математика гласит следующее: количество проверяемых цепочек это N-систем * M-интеграций между ними * K-релизов. Даже на примере 13 систем * 11 интеграций * 27 версий релизов получается примерно 3 861 возможных вариантов совместимости систем. Кажется, ответ очевиден автотесты? Но проблема чуть серьезнее, только автотесты не спасут. Учитывая растущее количество систем и их интеграций, а также различную частотность релизов, всегда имеется риск протестировать неправильную цепочку версий систем. Следовательно, имеется риск пропустить дефект в межсистемном взаимодействии, например, влияющий на корректность работы платежной системы (ПС) Мир.

Естественно, в ПРОДЕ наличие такого рода багов недопустимо, и задача нашей команды свести такой риск до нуля. Если помните текст выше, любой чих влияет не только на внутренние системы Mir Plat.form, но и на участников рынка: банки, торгово-сервисные предприятия (ТСП), физические лица и даже на другие платежные системы. Поэтому для устранения рисков мы пошли следующим путем:

Ввели единую базу выпуска релизов. Для этой задачи вполне хватило календаря релизов в Confluence с указанием версий систем, установленных в ПРОД;

Отслеживаем интеграционные цепочки в соответствие с релизными датами. Здесь мы тоже не стали изобретать велосипед, он нам потребуется дальше. Для решение данной задачи использовали Epic структуры в JIRA для интеграционного тестирования релизов. Пример структуры для релиза 1.111.0 системы System3:



С одной стороны, все эти действия позволили улучшить понимание команды о тестируемых интеграциях, версиях систем и последовательности их выхода в ПРОД. С другой все равно осталась вероятность некорректного тестирования вследствие человеческого фактора:
  1. В случае, если дату релиза какой-нибудь системы подвинули, то члену команды необходимо вручную поправить календарь и всю структуру в JIRA, в том числе сроки выполнения задач и, возможно, версии тестируемых систем;
  2. Перед тестированием интеграции необходимо убедиться, что окружение для тестирования состоит из нужных версий систем. Для этого необходимо вручную пробежаться по тестовым стендам и выполнить пару консольных команд.

Вдобавок появилась дополнительная рутинная работа, отнимающая иногда значительную часть времени.

Стало очевидным, что этот процесс подготовки к интеграционному тестированию релизов нужно как-то автоматизировать и по возможности объединить в один интерфейс. Вот тут и появляется наш собственный велосипед-спаситель: Система Мониторинга Интеграционного Тестирования или просто СМИТ.

Какие опции хотелось реализовать в разрабатываемой системе?
1. Наглядный календарь релизов с возможностью вывода версий всех систем на конкретную дату;
2. Мониторинг окружений для интеграционного тестирования:
список окружений;
наглядное отображение тестовых стендов и систем, входящих в состав отдельного окружения;
контроль версий систем, развернутых на тестовых стендах.
3. Автоматизированную работу с задачами в Jira:
создание Epic структуры релиза;
управление жизненным циклом задач на тестирование;
актуализация задач в случае сдвига даты релиза;
подкладывание allure-отчетов в задачи на тестирование.
4. Автоматизированную работу с ветками в Bitbucket, а именно создание релизных веток в проектах:
интеграционных автотестов;
автодеплоя интеграционного окружения.
5. Интуитивно понятный UI для запуска автотестов и обновления версий систем.

Что есть СМИТ


Так как система несложная, мы не стали особо мудрить с технологиями. Бэкенд написали на Java с использованием Spring Boot. Фронтенд на React. К базе данных особенных требований не было, поэтому мы выбрали MySql. Поскольку у нас принято работать с контейнерами, то все вышеперечисленные составляющие завернули в Docker, собирая при помощи Docker Compose. Работает СМИТ быстро и так же надежно, как остальные системы Mir Plat.Form.



Интеграции


Atlassian Jira. В джире создаются, открываются, принимаются в работу и закрываются задачи на тестирование каждой конкретной интеграции, если все тесты прошли успешно прикладывается ссылка на allure отчет в комментарии.
Atlassian BitBucket. В битбакете лежит код проекта автотестов, где инженеры по автоматизации ведут список окружений, настраивают его и добавляют/убирают системы в определенные окружения. Также там создаются релизные ветки под каждую новую версию системы, где будут вестись работы по актуализации кода и бизнес логики тестовых сценариев.
Jenkins. Все тесты из проекта автотестирования можно запускать через Jenkins, для каждого набора тегов у нас предусмотрена своя джоба. Отдельные джобы нужны для того, чтобы не грузить все шаги каждый раз, а загружать только нужные с помощью указания glue для Cucumber.
Системы. У СМИТа есть необходимость взаимодействовать с самими системами. Так СМИТ узнает актуальные версии систем путем выполнения определенных команд по ssh.

Ведение списков систем


Перед тем как в СМИТе вести календарь и мониторить состояние окружений, необходимо завести список тестируемых систем и взаимосвязи между ними. Все настройки можно произвести через веб-интерфейс:



После добавления тестируемой системы в список СМИТ:
  1. постучится на все хосты систем, имеющих название SYS_CMD в списке окружений;
  2. узнает версию этой системы с помощью команды, указанной в конфигурации;
  3. запишет к себе в базу текущую версию данной системы и окружения, в которых она фигурирует.


В итоге в СМИТе будет информация о всех системах, развернутых на используемых окружениях, включая номера их версий. На основе этой информации можно визуализировать календарь релизов.

Календарь релизов


После того, как владельцы систем или тим лиды команд разработки продуктов сообщают нам дату установки нового релиза в ПРОД, мы регистрируем этот релиз в календаре. Получается вот такая вот картина:



Можно легко заметить конфликты, где за несколько дней устанавливается сразу несколько релизов и возможна жара. Об этих конфликтах уведомляются владельцы продуктов, ведь ставить несколько новых версий систем в один день действительно опасно.

Также на странице с календарем имеется функция вывода версий всех систем на конкретную дату:



Стоит отметить, что при регистрации нового релиза в календаре СМИТ автоматически создает Epic структуру в Jira и релизные ветки в проектах в Bitbucket.

Состояние окружений


Еще одной очень удобной функцией СМИТа является просмотр текущего состояния конкретного окружения. На этой странице можно узнать перечень систем, включенных в окружение, и актуальность их версий.



Как видно на скриншоте, СМИТ обнаружил на хосте host-4.nspk.ru неактуальную версию System 4 и предлагает обновить её. Если нажать красную кнопку с белой стрелкой, то СМИТ вызовет Jenkins джоб на деплой актуальной версии системы в текущем окружении. Также есть возможность обновить все системы после нажатия соответствующей кнопки.

Окружения для интеграционного тестирования


Стоит немного рассказать про то, как мы задаем тестовые окружения. Одно окружение представляет собой некий набор стендов с развернутыми системами Mir Plat.form и настроенной интеграцией (на одном стенде одна система). В общей сложности у нас 70 стендов, разбитых на 12 окружений.

В проекте интеграционных автотестов у нас есть конфигурационный файл, в котором тестировщики задают тестовые окружения. Структура файла выглядит следующим образом:

{     "properties":{        "comment":"Общие system property для всех Environment. Могут быть переопределены персональными property, а также всем, что при запуске тестов в System.getProperties()",      "common.property":"some global property"   },   "environments":[        {           "comment":"Если отсутствует name, то Environment получит имя common + порядковый номер. Например common1",         "name":"env_1",         "properties":{              "comment":"Персональные system property данного Environment. Могут переопределять общие property. Могут быть переопределены всем, что при запуске тестов в System.getProperties()",            "env1.property":"some personal property"         },         "DB":{              "comment":"Пример TestResource'а DbTestResource. Если не указано поле id, то оно автоматически будет взято из ключа",            "url":"jdbc:mysql://11.111.111.111:3306/erouter?useUnicode=yes&characterEncoding=UTF-8&useSSL=false",            "driver":"com.mysql.jdbc.Driver",            "user":"fo",            "password":"somepass"         },         "SYS_CMD":{              "comment":"Пример TestResource'а на основе RemoteExecCmd. Должен иметь параметр type = remote",            "type":"remote",            "host":"10.111.111.111",            "username":"user",            "password":"somepass"         }      }   ]}


Помимо того, что данный файл необходим для работы проекта интеграционных автотестов, он также является дополнительным конфигурационным файлом для СМИТа. При запросе обновлении информации об окружениях в СМИТе отправляется HTTP запрос в API нашего bitbucket, где мы храним проект с интеграционными автотестами. Таким путем СМИТ получает актуальное содержимое файла конфигураций из master ветки.

Запуск тестов


Одной из целей создания СМИТа было максимальное упрощение процедуры запуска интеграционных автотестов. Рассмотрим, что же у нас получилось в итоге на примере:



На странице тестирования системы (в данном примере System 3) можно выбрать перечень систем, с которыми нужно проверить интеграцию. После выбора нужных интеграций и нажатия на кнопку Запустить тестирование, СМИТ:
1. Сформирует очередь и последовательно запустит соответствующие Jenkins джобы;
2. мониторит выполнение джоб;
3. меняет статус у соответствующих задач в Jira:
Если джоба отработала успешно задача в Jira будет автоматически закрыта, к ней будет приложена ссылка на allure-отчет и комментарий о том, что дефектов в данной интеграции не обнаружено.
Если джоба зафейлена задача в Jira останется открытой и будет ожидать решения от ответственного за интеграцию сотрудника, который сможет определить причину падения тестов. Ответственного за интеграцию можно подсмотреть в карточке интеграции.

Вывод


СМИТ был создан для минимизации рисков интеграционного тестирования, но нам как команде хотелось бОльшего! В частности, одним из желаний было, чтобы по одному нажатию кнопки автотесты запускались с правильным тестовым окружением, проверялось все в нужных интеграционных соответствиях, задачи в Jira сами открывались и закрывались вместе с отчетами. Такая утопия автотестеров: скажи системе, что проверить, и иди пить кофе :)

Подведем итог, что у нас получилось реализовать:
1. Наглядный календарь релизов с возможностью вывода версий всех систем на конкретную дату;
2. UI для отслеживания состояния наших окружений, позволяющий посмотреть перечень и версии систем, установленных на конкретном окружении;
3. Оповещение пользователей о неактуальных версиях систем с возможностью обновления до актуальной;
4. UI с интуитивно понятным запуском интеграционных автотестов для всей системы или для отдельных интеграций на определенном окружении;
5. Автоматическое создание и закрытие Epic и Task в Jira, прикладывание Allure отчетов к ним;
6. Автоматическое создание релизных веток в Bitbucket.

О планах на будущее


На данный момент система проходит закрытое бета тестирование среди непосредственных участников команды интеграционного тестирования. Когда все найденные дефекты будут устранены, и система стабильно будет выполнять свои функции, мы откроем доступ сотрудникам смежных команд и владельцам продуктов для того, чтобы у них была возможность самостоятельно запустить наши тесты и изучить результат.
Таким образом, в идеальном сценарии, всё, что потребуется сделать для проверки соответствия системы требованиям по интеграции зайти в веб интерфейс СМИТ, обновить через него необходимую систему, выбрать все галки и запустить тесты, а затем проверить, что они все выполнены успешно. Автоматически будут созданы задачи, заполнены allure-отчеты, проставлены соответствующие статусы этим задачам.
Подробнее..

Как мы подсчитали, сколько на самом деле может стоить разработка корпуса

07.09.2020 10:18:05 | Автор: admin

Тема уже из заголовка ясна: каждый день сталкиваюсь с непониманием того, сколько на самом деле стоит разработка корпуса.

И цель этой заметки рассказать вам о том, сколько действительно придётся за неё заплатить: 100 000 рублей, двести или миллион. Прочитав эту статью, вы сможете определить, сколько придётся отдать за работу и заодно понять, недоговаривают ли вам что-то разработчики по поводу цен или режут суровую правду.

Ответим на три основных вопроса:

Сколько нужно денег на разработку корпуса, почему столько и где можно сэкономить, если очень нужно?

Начну, как всегда, чутка издалека а из чего в принципе складывается цена корпуса? Если кратко, то вот:

Я уже писал на Хабре, как быстро оценить себестоимость производства корпуса и приводил примеры цен разных корпусов с разными параметрами. Но нигде и никто не пишет, сколько стоит собственно разработка корпуса. Вот самое время об этом написать с пруфами, Билли, примерами и цифрами, как я люблю.

Разработка поэтапно с человеко-часами за каждый этап

ТЗ

О том, из каких этапов состоит разработка корпуса, можно узнать из ещё одной нашей статьи на Хабре. Но это скорее внешняя сторона вопроса, а вот того, что происходит на нашей кухне, не видит никто (хотя процессы схожи с любой разработкой электроники или программированием например, с разработкой платы или софта на неё).

Сначала мы пишем за клиента ТЗ (скоро расскажем, почему сами). Для этого собирается первичная информация в виде опросника (скачать formlab.ru/useful), вытаскивается нужная инфа из разговоров с клиентом и его разработчиками, раскладываются по папкам референсы, модели, документация, и всё это отдается техническому писателю, который за 3-5 дней готовит простое техническое задание (мы его называем дизайнерское ТЗ). Формально там мало ограничений, кроме основных габариты, себестоимость производства, технологии, эргономика и т.д. Вот примеры: formlab.ru/tz.

Начинаем считать.

Технический писатель, составление ТЗ: +20 человеко-часов

Промдизайн

Дальше к работе подключаются промышленные дизайнеры тут все просто. Этот процесс сильно размазан во времени, потому что человеку надо прогреться, т.е. поварить в голове задачу, посмотреть на конкурентов, прикинуть, что вообще можно сделать, и рисовать рисовать рисовать

Средний проект занимает 2-3 недели работы дизайнера. Обычно их на проекте двое. Половина времени тратится на поиск стиля будущего корпуса, а половина на более детальную прорисовку того, что напридумывали.


Хозяйке на заметку: если дизайнер говорит, что все сделает в 3D, потому что сейчас уже никто не рисует, то знайте, что он работает раза в 1,5-2 медленнее, чем дизайнер, который рисует руками. Такой в 3D вам обойдётся вдвое дороже, короче.

дизайнеров смотрят на меня сейчас так, простите, коллеги, но это статистика лет так за десять уже :)

Промышленные дизайнеры, прорисовка эскизов +80 человеко-часов.

Моделирование

Затем корпус надо прорисовать уже в 3D и подготовить визуализацию. Это либо тот же дизайнер, либо отдельный моделлер (у нас отдельный, кстати) и визуализатор (у нас отдельного нет) ещё неделя.

Модель и визуализация дизайна корпуса в 3D +40 часов.

Инжиниринг

А вот дальше начинается самое интересное это инжиниринг корпуса. Абсолютно внутренняя штука, которую заказчик даже и не видит иногда. Но чаще видит, поскольку проходит итерационная работа между конструктором корпуса и разработчиком платы. В общем процесс выглядит так:

При необходимости возвращаемся на прорисовку геометрии и дальше по кругу.

Инжиниринг во всех наших проектах занимает больше времени, чем разработка дизайна. Другого не дано. Простой корпус (о сложности ниже расскажу) это работы на месяц как минимум (а с бумажками два!). Про сроки, кстати, писал вот тут, почему-то нет на Хабре возьму на заметку.

Инжиниринг корпуса, согласование с производством +160 часов.

Прототипирование

Добавим в копилку проекта еще 50 часов на работу конструктора.

50 часов это ещё нижняя планка, когда конструктор и завод просто не то что знают друг друга, а лет эдак 5 работают в тесном контакте.


Хозяйке на заметку если вы считаете, что прототип это только сам прототип, т.е. его физическое изготовление, то ошибаетесь: это куча работы до, во время и после производства. И всё это нередко дороже и сильно дольше непосредственно производства.

Итак, в копилке 350 человеко-часов на простой корпус. Вопрос: сколько же стоит такой человеко-час? Об этом ниже, так как все не так однозначно.

Как оценивать сложность корпуса

Я специально беру в пример простой проект, так как их большинство и мы уже в них собаку съели два из трёх корпусов, которые у нас заказывают, именно простые.

Но есть другая треть, которую уже сходу не оценить. И как понять на берегу, простой корпус или сложный?

Очень просто: оценка сложности проекта это количество деталей + сложность их соединения друг с другом. Представьте, сколько деталей в корпусе вашего устройства: кнопки, стекла и вот это все.

Вот простенькая схема для оценки сложности корпуса по количеству деталей:

Затем решаете: нужны ли деталям какие-то особые соединения? Например, герметичность. Или виброустойчивость. Или гибкость. Или вентиляция платы особенная, а не просто отверстий наделать

Если что-то из вышеперечисленного требуется, ваш корпус почти наверняка (но не всегда) будет сложным. Проблема в том, что физические свойства в виртуальной среде можно только имитировать, и очень условно, но для полноценной проверки (герметичен ли он на самом деле ил нет) потребуются несколько прототипов и куча работы. Поэтому с вероятностью 90% этап прототипирования будет дольше по времени и обойдётся дороже первичной разработки.

Или в корпусе просто много деталей тогда просто количество рутинной работы по их сопряжению превращается в десятки и даже сотни часов разработчика.

Примеры простых корпусов:

Средние по сложности корпуса:

Сложные корпуса:

Прототипирование часы (минимум-среднее): 50 часов.

Опоздатушки

Вам нужен корпус, вы приходите в компанию разработчиков и они вам обещают, что разработают корпус за месяц. Вы, если опытный боец, уже знаете, что это очень оптимистичная оценка по времени, и закладываете в бюджет 2Х от цены и сроков. Если прям опытный-опытный то 3Х.

Если не очень опытный и верите на слово, через месяц вы видите, что у вас даже еще контракт не согласован, потому что на это есть пара десятков внешне уважительных причин и куча обоюдных тормозов.

Ещё на проект наслаивается такая штука, как ожидания заказчика на этапе заключения договора. Все, кто оказывает сложные услуги, про это знают, но вдруг кто-то нет, рассказываю

Не буду сильно растекаться по древу, почему это происходит, просто кратко если только над проектом работает больше 2х людей, все оценки и прогнозы надо умножать минимум на 2. Я даже как-то статистику составил за 3 года (это примерно 120 проектов), сравнивая время на разработку: то, которое обсуждали в начале проекта и то, сколько он фактически длился.

Так вот, все проекты, даже так ВСЕ проекты заняли минимум вдвое больше времени, чем планировалось изначально. А есть проекты, которые съели человеко-часов и втрое больше, и впятеро. Поэтому ещё пара советов.

  1. Не считай, что твои внутренние процессы не задерживают разработчика вы одинаково тормозите друг друга.

  2. Не меняй в ТЗ ничего. Если есть хоть какая-то вероятность замены, например, компонента, готовься к кратному увеличению и сроков, и бюджета.

  3. Переходи на ЭДО возня с физическими бумажками отожрёт до 30% от срока согласований, и это практически на пустом месте.

Внесение правок

Ну и второй важный вопрос внесение правок, которые могут запросто сломать всю предыдущую работу и поставить перед фактом Вам придётся начать всё заново.

Но это нормально, мы, в конце концов, все с вами делаем новые штуки, тут проложенных рельсов нет ни у кого.

Часы на внесение правок: непрогнозируемо. Иногда правки незначительны, иногда работу приходится просто переделывать.

Разные подрядчики разные чеки

А теперь, собственно про деньги.

Одну и ту же работу можно сделать разными исполнителями, я даже как-то это описывал вот тут, но слушать больно звук писался из зала, простите. Суть в следующем выбирайте подрядчика в зависимости от своих процессов и желаемой степени контроля и погружения в ваш проект.

Вот разные типы подрядчиков, которые могут разработать для вас корпус. У каждого есть достоинства, недостатки и, условно, средний чек нормо-часа:

Т.е. если бы ваш проект делал свой сотрудник, то он бы, допустим, сделал его за 175К и примерно 2 месяца работы фуллтайм, т.е. 8 часов в день, прям плотнячком. Фрилансер за 350К, студия за 500К, а бюро за 700К.

И, конечно, вывод однозначен:

Если результат одинаков, зачем платить больше?

Но так не работает, такие дела. Штука именно в издержках, возникающих в процессе разработки штатный сотрудник не сможет и нарисовать все хорошо, и сделать документацию, и все согласовать с заводом (который сам же и должен найти). Для одного проекта таких сотрудников надо уже 3 человека если по-хорошему.

Фрилансер может уже больше, но там есть тайланд-головного-мозга другие риски. И, опять же, всем, что связано с прототипами (не макетиками на 3D-принтере, а когда все серьезно), вы будете заниматься сами.

Бюро тоже не ангел все сделаем за вас, но и возьмем больше всего денег.

Еще важный момент профессионализм, т.е. количество ошибок и проблем. Штатного сотрудника ты знаешь, знаешь, что он может, а чего нет. Можно предположить, где он ошибется (кстати, вот тут чуваки влетели на 12М из-за ошибки штатного конструктора formlab.ru/12mln-v-minus).

С фрилансером всё не так прозрачно по сути, ты просто веришь в него. Чем выше уровень подрядчика (квалификация, число реализованных проектов, количество спецов в компании и пр.), тем лучше качество услуги, что логично суммарный опыт внутри бюро или студии больше, чем у одного человека. Но и сумма чека за этот опыт тоже увеличивается.


В конечном итоге всё сводится к очень простому вопросу: кого выбрать?

Если ты считаешь свое время самым дорогим и тебе нужно добежать до продаж продукта максимально быстро и не рискуя, то платишь бюро.

Если хочется всем рулить, т.е. тратить на задачи свое время, а срок выхода на продажи не давит обращай внимание на левую часть таблички, где чек будет минимальным. Так можно сэкономить. Подробнее про экономию ниже.

Экономим как?

В разработке всегда есть такая штука, как коммуникативные издержки. Под этим словосочетанием я подразумеваю весь комплекс коммуникаций с заказчиком. Но самое фантастическое заключается в том, что стоимость издержек может быть равна стоимости работы над проектом. Наглядный пример: на фактическую работу, условно, ушло 3 недели, на обсуждения и согласования год.

И тут ты:

  1. либо берешь коммуникации на себя, т.е. занимаешься проектом полностью, по сути, оплачивая несвязанность разработчиков (электроника, дизайн, инжиниринг, производство);

  2. либо перекладываешь все это на специальных людей, но тогда платишь им за это + за профессионализм разработчиков (опытный специалист делает меньше ошибок), т.е. либо ты готов рисковать и работать на веру, либо хочешь подстелить, потому что важно быстрее выйти на производство и начать уже продавать свой продукт.

Первый путь это про экономию, второй про скорость выхода на продажи.

Примеры

Ну и слайды-слайды примеры с цифрами:

Компактный корпус 200 000 ($ 3000) https://formlab.ru/portfolio/vk7

Компактный герметичный корпус 350 000 ($ 5000) https://formlab.ru/portfolio/vk

Корпус в стойку 450 000 ($ 6500) https://formlab.ru/portfolio/case19

Настенный многофункциональный корпус 500 000 ($ 7000) https://formlab.ru/alarm_system_pritok

Корпус светильника 600 000 ($ 8500) https://formlab.ru/portfolio/dragonfly

Настольный корпус 600 000 ($ 8500) https://formlab.ru/helium_leak_detector

Носимый сложный корпус 700 000 ($ 10 000) http://old.formlab.ru/promyishlennyiy-4g-modem-dlya-televizionshhikov-mobile-4g-router/

Носимый сложный корпус 800 000 ($ 11 500) https://formlab.ru/analyzer

Носимый сложный корпус 1 000 000 ($15 000) https://formlab.ru/luch

Напольный сложный корпус 1 200 000 ($ 17 000) https://formlab.ru/gamma_complex

Напольный сложный корпус 1 700 000 ($ 25 000) https://formlab.ru/bankomat_sberbank

Кабина станка 3 000 000 ($ 45 000) https://formlab.ru/mclt_2

Ценники усредненные, плюс дополнительно суммы даны в долларах (на 4 августа 2020 года): просто оценить порядок бюджета.

Выводы

Цель заметки, как я уже писал, показать, как появляется формируется цена в разработке корпуса, точнее, как это делаем мы в Формлабе, и сколько в итоге придётся потратить на корпус.

Вы уже знаете, из каких этапов состоит работа и понимаете, сколько человеко-часов придётся на всё потратить. Кроме прочего, у вас уже есть табличка с примерными расценками каждого специалиста.

Вывод банальнее некуда: правильная разработка не может стоить. Ну, вы поняли.

Но, к счастью, и способы сэкономить тоже имеются.

Что ещё почитать по теме:

Где выгоднее производить корпуса в Китае или России? Мы сравнили, пользуйтесь
Макет, прототип, серийный образец и вот это всё учим термины
Российское приборостроение: вертели мы ваш дизайн на пальцах
Как спроектировать корпус для прибора. Полное руководство
Как не промахнуться с бюджетом на серийное производство корпусов: 20 примеров из практики бюро по инженерному дизайну
Как не промахнуться с бюджетом на серийное производство корпусов-2: цены на мелкосерийное литьё пластика
Правильно готовим прототип. Технологии прототипирования корпуса
Как за пару минут самостоятельно рассчитать цену корпуса устройства
Промышленный дизайн для бизнеса: минимизируем издержки, экономим на ненужном, вкладываем в главное
Промышленный дизайн для бизнеса, часть 2: дизайн вместо маркетинга или делаем продукт, который продаст себя сам

UPD: чтобы 2 раза не вставать скоро выходит вторая часть нашего гайда, с обновлением статей и новыми материалами. Кому хочется обновлений, велкам сюда: formlab.ru/habr.

Подробнее..

Маленькие тайны тестирования большой LMS

09.09.2020 12:15:30 | Автор: admin


Редко получается найти проект, в который влюбляешься еще на собеседовании и которым гордишься, когда он завоевывает новые рынки. Тем более приятно, когда профессионализм коллег на высоте, а в своей команде чувствуешь себя как в кругу семьи. Мне повезло не только найти такой проект, но и некоторое время назад начать влиять на процесс тестирования в нём. Я расскажу, что входит в наше понимание оптимального процесса; как мы пришли к ежемесячным релизам и как они у нас работают; а также о том, как мы приспособились к условиям карантина.

Наш проект представляет собой систему дистанционного обучения (LMS, Learning Management System), которой пользуются более 7 миллионов человек в разных странах мира. В системе 1000+ веб-страниц и порядка 10 000 тест-кейсов.



Сейчас в проекте работает около 15 команд разработки со стороны заказчика в Норвегии и со стороны Аркадии в России. Я присоединилась к проекту 8 лет назад в качестве QA; последние 2 года я работаю в качестве QA lead, участвуя в оптимизации процесса тестирования.

Что входит в понятие оптимального процесса


Наша главная задача удовлетворение нужд конечных пользователей, что включает создание нового функционала и поддержку системы. Особое внимание уделяется скорости работы системы и стабильности работы в условиях большой нагрузки.

Процесс разработки в первую очередь должен позволять устойчиво достигать бизнес-целей, таких как выполнение работы в срок и с оговоренным уровнем качества. Но процесс также должен быть комфортным для команды разработки, чтобы все участники процесса были удовлетворены. В наших командах мы наладили оптимальный для нас процесс, и вот какими средствами это достигается.

Процесс разработки в целом:


a) Подход к разработке, удовлетворяющий нужды команды
Мы работаем, используя Scrum и спринты продолжительностью 3 недели. Перед спринтом проходит презентация его целей и формируется набор требований для данного спринта. Далее идет планирование, на котором мы оцениваем все задачи и определяем набор задач, который войдет в спринт. По окончании спринта проходит Sprint review, на котором мы демонстрируем все выполненные задачи и анонсируем достигнутые цели. Такой подход для нас является оптимальным: за спринт мы успеваем сделать достаточное количество новой функциональности и при этом исправить и протестировать определенное количество багов от конечных пользователей на такие баги выделяется 10% времени спринта.



Состав команды: team lead, разработчики, тестировщики. Соотношение разработчиков к тестировщикам в наших командах 3:1. Такое соотношение дает возможность достигать цели спринта равномерно нет периодов, когда кто-то из участников процесса простаивает: пока разработчики делают какое-либо изменение, тестировщики создают или обновляют тест-кейсы, относящиеся к этому изменению; когда разработка закончена, тестировщики проверяют изменения, а разработчики либо переходят к следующим задачам спринта, либо помогают в тестировании (это бывает необходимо при тестировании масштабных изменений).
Product Owner определяет цели и требования в начале каждого спринта и принимает в конце. Также у каждой команды есть Scrum Master, который помогает решать возникающие проблемы.



Для того, чтобы команда имела возможность проводить различные активности, не относящиеся непосредственно к задачам спринта, а также учитывая различные риски, время, рассчитанное на выполнение задач спринта, составляет 80% от всего рабочего времени команды. То есть 2 часа в день в течение обычного спринта резервируются на коммуникации, различные совещания и семинары, а также исправление багов, найденных в спринте.

b) Четкие требования и хорошее планирование
Для того, чтобы планирование не затянулось, а спринт не стал провальным из-за неизвестных ранее деталей и трудоемких дополнительных изменений, добавленных уже в процессе спринта, мы стараемся брать в спринт только изменения с достаточно ясными и четкими требованиями. Если область проекта, которая касается изменений, неизвестна команде, или в течение планирования возникает много вопросов, на которые Product Owner не может дать ответов, команда может взять в спринт задачу на изучение данной области либо задачу на исследование, результатом которого становятся четкие требования или даже некий прототип.

c) Ретроспективы
Работа над ошибками тоже важна. Это касается как спринтов, так и релизов. Случается, что мы что-то не успеваем, или приходится работать сверхурочно, чтобы успеть в срок например, при необходимости дотестировать релиз (а это дополнительные расходы, которых компании хотелось бы избежать в дальнейшем). Поэтому мы проводим ретроспективы, на которых обсуждается, что было хорошего и плохого в спринте или релизе, и вырабатываются меры для избежания таких ошибок в дальнейшем.

d) Поддержка со стороны менеджмента
Иногда возникают вопросы или ситуации, которые невозможно разрешить на уровне команды нужно менять процесс или привлекать к решению менеджмент компании. Очень важно видеть, что тебе хотят помочь и готовы поддержать в такой ситуации. У нас в компании с этим все хорошо это касается как Аркадии, так и менеджмента со стороны заказчика. Все вопросы обсуждаются и всегда находится решение, удовлетворяющее все стороны.

e) И, на мой взгляд, основополагающее это хорошая коммуникация. И то, что есть у нас в компании, для меня является одним из главных преимуществ комфортной работы доброжелательность, желание идти на компромиссы.
Это касается всех: и каждого члена команды, и Product Owner, и Scrum Master, и менеджмента компании, и многих других участников процесса. Все открыты для вопросов и обсуждений, разработчики советуются с тестировщиками в вопросах требований и вместе решают, как лучше (и с точки зрения разработки, и с точки зрения тестирования) сделать то или иное изменение. Product Owner, в свою очередь, постоянно на связи с командой, оперативно решает все вопросы и всегда старается идти навстречу в достижении целей спринта. Scrum Master всегда готов помочь: найти дополнительные ресурсы (тестировщиков/разработчиков, если они требуются для спринта или для релиза) или подсказать, как лучше организовать спринт по времени.

Процесс тестирования:


a) QA-стандарты (guidelines), относящиеся к написанию тест-кейсов.
У нас в проекте тест-кейсы являются основной детальной документацией по функционалу системы, поэтому им уделяется большое внимание. Для каждого изменения, сделанного командой, пишется новый тест-кейс или обновляется уже существующий.
Раньше, когда система была еще не такой огромной, тест-кейсы писались достаточно детальные, с различными конкретизированными шагами, но сейчас этот подход стал неприемлем на обновление таких тест-кейсов уходит очень много времени. Поэтому мы (QA leads) разработали стандарты, основным требованием которых является написание сценариев тестирования с ожидаемыми результатами вместо детально расписанных шагов в тест-кейсах.

b) QA-стандарты, относящиеся к тестированию в спринтах.
Чтобы каждая команда обеспечивала хорошее качество сделанных изменений, были разработаны стандарты тестирования в спринте.
Основа этих стандартов максимальное покрытие тестированием, куда входит:
Тестирование непосредственно сделанного командой изменения (функционал и при необходимости UI);
Тестирование системы после этого изменения с использованием чек-листа: это обязательные проверки, к которым относятся тестирование доступности для людей с ограниченными возможностями, проверка переводов, проверка существующих данных, тестирование с использованием специальных символов, проверки безопасности, тестирование изменений в мобильном приложении и другие проверки.

c) QA-стандарты, относящиеся к тестированию релизов.
Релизный процесс и стандарты, используемые в нем, более подробно рассмотрим ниже.

d) Использование автоматизированного регрессионного тестирования.
Создание автоматических тестов для регрессионного тестирования сильно облегчило жизнь команд теперь, если требуется проверить какую-то область после командных изменений, можно просто запустить регрессионные автотесты для нужной области системы (если данная область покрыта автотестами). Также, если какая-то часть системы была сломана изменениями команды, регрессионные автотесты это выявят.

e) Взаимовыручка тестировщиков, помощь разработчиков.
У нас не очень много тестировщиков (в среднем 1 тестировщик на 3 разработчиков), к тому же время от времени они отвлекаются от задач спринта на тестирование релизов, и времени на всё может не хватать.
В таком случае всегда находится кто-то из тестировщиков других команд с меньшей нагрузкой в текущий момент, кто может помочь. Найти такого тестировщика помогает QA lead или Scrum Master. Кроме того, разработчики могут помочь с тестированием изменений в спринте, если по ним уже написаны тест-кейсы.

f) Коммуникация между тестировщиками.
Для коммуникации используется чат в Microsoft Teams, в котором каждый может задавать вопросы и оперативно получать ответы, а остальные тестировщики при этом узнают актуальную информацию. Также у нас проходят ежемесячные QA-митинги, на которых тестировщики делятся друг с другом текущими задачами своей команды и могут обсуждать любые вопросы подход к тестированию и/или расположение тест-кейсов, касающихся незнакомой для тестировщика области; вопросы по релизу (состав будущей релизной команды, изменение сроков тестирования); дополнительные обязательные проверки, добавленные после пропуска критичного бага в релизе, и т.д.).

Перечисленные выше подходы позволяют обеспечить хорошее качество тестирования в спокойном рабочем режиме.

Чем хороши ежемесячные релизы и как мы к ним пришли: организация процесса тестирования во время релиза


Раньше у нас были квартальные релизы. При таких временных рамках к каждому релизу скапливалось достаточно много изменений, которые были сделаны командами. Такой объем изменений, безусловно, требовал регрессию перед релизом, поэтому для регрессии выделялся отдельный период времени, и к ней подключались все команды. Обычно это занимало около 2 недель, и в регрессии участвовали как тестировщики, так и разработчики команд.

Через какое-то время для регрессии в процессе тестирования релиза стали использоваться автотесты. Не все тесты для регрессии были покрыты автотестами, что-то тестировалось вручную. В целом это сократило время тестирования регрессии, но из-за объемов системы полная регрессия все еще занимала много времени.

Весь цикл разработки выглядел примерно так:



Стало очевидно, что такой подход к релизам не оптимален, чрезмерно трудозатратен и не позволяет быстро и гибко удовлетворять запросы конечных пользователей. Подход к релизному процессу требовал изменений, и было принято решение проводить релиз чаще раз в месяц.

Когда мы перешли на ежемесячные релизы, стало ясно, что времени на проведение регрессии на этапе тестирования релиза уже нет даже с использованием частично автоматизированных тестов для регрессии. Сейчас общий период подготовки к релизу занимает всего 2 недели. Поэтому теперь регрессия делается в спринтах и только при необходимости (если разработчики сообщают, что требуется регрессия определенной части системы).

Но так как на этапе тестирования релиза необходимо проверить не только новый функционал, но и общее состояние системы, мы стали использовать стабилизацию вместо регрессии.

Стабилизация включает в себя:

a) тестирование нового функционала, включенного в данный релиз каждой командой;
b) тестирование критичных областей это проверка основной функциональности главных областей системы (что, очевидно, занимает гораздо меньше времени, чем полный цикл регрессии);
c) тестирование багов, найденных в командных изменениях для данного релиза.

Весь цикл разработки теперь выглядит так:



Рассмотрим, что еще необходимо для подготовки к релизу.

Когда стабилизация закончена и релизный пакет имеет хорошее качество, прежде чем выкатывать его на production, проводится тестирование конфигурации на pre-production окружении. Таким образом Operations практикуются обновлять окружение, а тестировщики проверяют конфигурацию с текущим релизным пакетом до реального релиза.

Можно подумать, что 2 недели подготовки к релизу это слишком много, и на тестирование в спринте остаётся мало времени. Но обычно у тестировщика подготовка к релизу занимает 4-6 дней. Это зависит от:

сложности и объема функционала, который его команда собирается выпускать,
участия тестировщика в релизной команде текущего релиза.

Все тестировщики проекта (включая релизную команду) участвуют в тестировании стабилизации; тестирование конфигурации и непосредственно самого релиза делает только релизная команда.

Общее расписание тестирования релиза выглядит так:



Так как критичные области и конфигурация содержат постоянные тесты, мы частично автоматизировали эти тест-кейсы. Это значительно сократило время тестирования при подготовке к релизу, поэтому в дальнейшем мы планируем расширить использование автотестов.

С точки зрения организации тестирования для каждого релиза выбирается QA-координатор (кто-то из QA leads). Времени на подготовку к релизу для QA-координатора обычно планируется больше, чем для обычных тестировщиков, так как у QA-координатора больше обязанностей. К ним относятся:

  • определение релизной команды и проверка доступности всех ее участников на время релиза;
  • подготовка тест-планов для релиза;
  • запуск автотестов на этапе стабилизации и тестирования конфигурации;
  • координация работы тестировщиков во время тестирования релиза;
  • помощь тестировщикам в решении всевозможных вопросов, связанных с релизом;
  • контроль за выполнением тестирования и при необходимости перераспределение нагрузки для помощи в тестировании перегруженным командам (это могут быть либо тестировщики других команд, которые уже закончили релизное тестирование, либо разработчики команды, либо сам QA-координатор).


И конечно, ни один релиз не обходится без возникающих проблем. Мы их решаем и разрабатываем план, как избежать их в дальнейшем. Вот некоторые, с которыми мы сталкивались в последнее время:

  • Проблема: иногда команды добавляют свои изменения в релиз в последний момент перед началом стабилизации, из-за этого стабилизация начинается позже, и обычно такие изменения содержат баги, потому что из-за спешки их могли не очень тщательно протестировать в спринте.
    Решение: стараемся избегать добавления таких опасных изменений.
  • Проблема: баги находятся на этапе тестирования конфигурации на pre-production окружении. Это слишком поздно приходится исправлять и пересобирать релизный пакет.
    Решение: после таких ситуаций мы обновляем критичные области на стабилизации.
  • Проблема: увеличение времени на тестирование релиза, что может быть причиной сдвига даты релиза.
    Причинами увеличения времени могут быть следующие факторы:
    a) сдвиг релиза в целом по каким-то веским причинам и тем самым больший объем командных изменений в релизе (время между релизами не месяц, а несколько месяцев),
    b) нестабильная работа окружения для тестирования стабилизации или конфигурации,
    c) конфигурационные баги окружения,
    d) большое количество нетривиальных багов команды, найденных на стабилизации. Как правило, это интеграционные баги, связанные с изменением одной области разными командами.
    Решение: в таких случаях мы стараемся успеть протестировать всё необходимое для релиза, даже если это требует участия в релизе все 2 недели или сверхурочную работу, так как релиз является более приоритетной задачей, чем задачи спринта.


Но какие бы проблемы ни возникли, мы всегда можем их решить силами релизной команды или привлекая людей, компетентных в той или иной области главное, что это всегда слаженная командная работа, приводящая к хорошему результату.

Работа в условиях карантина: как обеспечить работу тестировщиков


В нашем проекте обязательным условием является работа из офиса. Это сделано для того, чтобы любого участника процесса можно было найти в рабочее время если вдруг он не отвечает в чатах, то работающие с ним люди могут сообщить ему, что он необходим кому-то из коллег. Это актуально, потому что часть команд находится в Норвегии, а часть в Санкт-Петербурге.

В период пандемии, когда и Норвегия, и Россия отправили большинство населения на самоизоляцию, нам пришлось перейти на удаленную работу.

Мы продолжили работать в обычном режиме: команды всё так же заканчивали спринты с хорошими показателями продуктивности спринта, а релизы выпускались в назначенные сроки.

Коммуникация все так же оставалась на хорошем уровне приложение Teams покрывало все нужды: активные беседы шли в чате, митинги проходили без проблем; если были какие-то вопросы, которые нужно было срочно обсудить, созванивались с любым участником проекта.

С точки зрения организации тестирования, проблем не было: в рабочие часы все тестировщики отвечали в чатах и оперативно участвовали в тестировании релиза. На случай, если нужно найти кого-то, а он не отвечает в чате, мы заготовили список номеров мобильных телефонов, но нам ни разу не пришлось им воспользоваться.

Единственная проблема, с которой мы столкнулись, сидя дома на удаленной работе в силу особенностей VPN невозможно было тестировать систему на командном окружении с телефонов/планшетов. Но эту проблему удалось обойти спасибо менеджеру проекта и IT-службе, которые нашли решение. Мы стали использовать прокси при подключении по домашней сети, и теперь можем тестировать на мобильных устройствах из дома.

Сейчас мы частично возвращаемся к работе в офисе, но часть компании продолжает работать из дома. И даже находясь в разных частях города, мы всё так же остаемся единой сплоченной компанией, которая продолжает работать в такое нелегкое время, с такими нерабочими условиями, когда дети и домашние животные требуют внимания, интернет тормозит и периодически пропадает, свет выключается, и столько отвлекающих факторов, что вообще не понимаешь, как же получилось в очередной раз поработать?!

Но вместе мы всё это переживем, и наконец-то вернувшись к полноценной офисной жизни, будем улыбаться друг другу еще шире, чем обычно.

Заключение


Подводя итог вышесказанному, хочется отметить несколько моментов:

  1. В большом долгосрочном проекте возможно организовать оптимальный процесс, при котором будет достигнута удовлетворенность как конечного пользователя, так и всех участников процесса разработки. И наш проект тому пример.
  2. Безусловно, путь к оптимальному процессу пройдет несколько итераций, пока не найдутся нужные средства и подходы.
  3. Какие бы средства и подход ни были выбраны, какими бы профессионалами ни были участники процесса, на мой взгляд, основополагающее в проекте это коммуникация и доброжелательная атмосфера. Именно благодаря им проект сможет достичь высот, а каждый участник процесса разработки сможет любить свой проект и с удовольствием делать все возможное для его развития.
Подробнее..

ERP-система управление показателями на стыке коммерции и IT

09.09.2020 14:04:11 | Автор: admin

Вообще заголовок у этой статьи должен быть сильно длиннее.

ERP-система RocketSales: управление показателями на стыке коммерции и IT.
С интеграцией с amoCRM и платформой для управления проектами Asana.
С тайм-трекингом и KPI, основанной на человекочасах.
С полной и чертовски сквозной автоматизацией.
В условиях пандемии и вынужденной удаленки.

Всем привет. На связи снова @kuznetsov_rocket. В этой статье я хочу показать вам, как мы в RocketSales организовали учет и планирование ресурсов команды. Показывать буду с точки зрения активного пользователя, но много расскажу и про техническую сторону решения.

Короткая история, которая даст мотивацию читать до конца

Мы задумали делать свою ERP-систему, чтобы видеть, на что уходят ресурсы команды, эффективно ими управлять.

Собрали рабочую группу, оценили объем работ нашей команды в 200 часов. При условии, что над проектом с высоким приоритетом работает 4-5 человек - это 1, ладно, 2 месяца до полностью готовой системы.

Начали делать.

В итоге, проект растянулся на год. Я негодовал, почему так неэффективно, топ-менеджмент недоумевал, почему так долго, менеджер проекта выбился из сил, потому что не ожидал, что будет так сложно.

Хорошо, хоть своими силами разрабатываем. Не надо платить подрядчикам

Но, ведь, сотрудники получают деньги за потраченные на задачу часы.

Минимальный функционал системы мы реализовали довольно быстро, поэтому сразу начали вести в ERP учет затраченного времени и стоимости проекта. Да, вот так забавно вышло, разрабатывали систему и в ней же фиксировали, сколько на эту разработку ушло ресурсов.

В итоге, разработка собственной ERP-системы обошлась нам в 2 490 часов. Это больше, чем в 10 раз превысило наши ожидания. Средняя ставка часа среди компаний, которые разрабатывают такие решения на заказ, составляет 3 000 рублей. Если оценивать подобный проект по рыночной цене, выходит около 7,5 млн. рублей.

На скриншоте - карточка проекта по разработке ERP в нашей же ERP. Здесь видно, сколько всего часов потратили сотрудники, кто участвовал в проекте.

Можно также посмотреть карту касаний по проекту: график активности сотрудников в течение всего времени его существования. На скриншоте видно, что работа над ERP продолжается до сих пор.

Зачем мы вообще затеяли разработку собственной системы учета ресурсов?

Команды делают огромную работу, а собственник или руководитель даже не могут понять: откуда на такую рядовую задачу столько часов, денег, почему мы целый год это делали.

В ERP ты видишь: 2 490 часов - огромный объем задач. Абсолютная прозрачность по сложности проекта и эффективности каждого в команде. Вот бэклог из карточки проекта в Asana (платформы для управления проектами).

Без такой системы оценка проектов производится на глаз. А если исполнителем выступает подрядчик, то такой интуитивный подход не просто растянет реализацию на неопределенный срок, но и сильно увеличит бюджет проекта.

Ты даже не можешь спрогнозировать, сколько денег тебе понадобится.

Спрашиваешь у подрядчика: А сколько денег нужно?

Он говорит: А мы не знаем, будет зависеть от количества часов.

Даешь 500 тысяч, они заканчиваются.Подрядчик просит еще.

Спрашиваешь: А сколько еще нужно?

Он отвечает: А мы не знаем, будет зависеть от количества часов.

И ты даешь еще 500 тысяч, и они снова заканчиваются, в отличие от проектной работы.

ERP-система не только помогает контролировать текущие проекты. Сейчас мир все чаще работает по методологии Agile, когда все проекты непредсказуемо гибкие. Но с ERP, на основе опыта и статистики предыдущих проектов, ты точно можешь оценить проект и знаешь, сколько будет стоить его повторить.

Что за зверь, эта ERP-система?

ERP - от англ. Enterprise Resource Planning, планирование ресурсов предприятия. Это концентрат огромного объема информации. Главная цель внедрения ERP в компанию - отслеживание постоянно обновляемых показателей, позволяющих оценить текущие затраты ресурсов по отношению к маржинальности и другим параметрам успешности деятельности команды.

В RocketSales ERP собирает данные из трех систем:

  1. amoCRM, в которой мы ведем продажи и некоторые этапы производства,

  2. Asana, в которой мы ведем проекты и задачи компании,

  3. TimeDoctor, в котором мы фиксируем время работы каждого сотрудника.

Расскажу чуть подробнее про организацию процесса в каждом из инструментов.

amoCRM

Мы не только внедряем amoCRM клиентам, но активно используем ее сами. И с улыбкой смотрим на конкурентов, которые внедряют клиентам Битрикс24, а сами ведут продажи в amoCRM.

amoCRM у нас, в основном, инструмент отдела продаж. Но в воронке продаж присутствуют этапы производства, в которых в обязательном порядке фиксируются дедлайны и следующие параметры:

  • бюджет,

  • дата передачи в производство,

  • расчетный фонд времени на реализацию проекта.

Примечание. Как мы считаем время, которое понадобится на реализацию задачи.

В расчетный фонд времени мы закладываем количество часов на выполнение всех блоков работ, включая обучение, сопровождение. Для отдела продаж мы разработали специальный калькулятор услуг.

На основании опыта мы оценили каждую услугу в часах, прописали стоимость часа для работы каждого сотрудника. В калькулятор мы заложили формулы, которые с учетом заданных условий позволяют планировать время и стоимость комплексных услуг. Система считает отдельно каждую услугу и добавляет умножающий коэффициент, если есть факты пересечения услуг, повышающие сложность реализации.

Менеджер проекта тоже работает в CRM-системе. При приеме в производство он заполняет кастомные поля:

  • дата приема и сдачи работ,

  • важные примечания.

При переносе сделки на этап Принят в производство в ERP автоматически создается новый проект. Из amoCRM, при помощи разработанного нами виджета, в 1 клик проектный менеджер создает одноименный проект в платформе Asana. Посмотрим, какие данные наша ERP вытаскивает из Asana.

Asana

Про это я подробно рассказывал в предыдущей статье. Мы фанаты Asana, их первые сертифицированные партнеры в России. Мы внедряем ее клиентам, консультируем команды по 200-300 сотрудников и даже запустили свой обучающий курс по самостоятельному внедрению Asana в процессы команды.

Вкратце: из amoCRM мы "прокидываем" проект в Asana. В Asana происходит вся коммуникация по задачам клиента. Туда мы вносим новые задачи, если есть необходимость в доработке. Там фиксируем промежуточные статусы.

В том числе благодаря ERP мы вывели в Asana панель быстрого контроля ресурсов. Наводишь на плашечку над задачей и видишь, кто и сколько работал над задачей, какую премию заработал.

Понять, сколько и над какой задачей работали сотрудники нам помогает TimeDoctor. Перейдем к нему.

Time Doctor

Каждый день каждый сотрудник фиксирует время работы. Сел за компьютер, выбрал задачу, над которой трудишься, нажал Play, таймер начал отсчет.

Видно время, отработанное сегодня. Понятно, над какими задачами, когда и сколько ты работал.

Time Doctor - достаточно агрессивная система для тайм-трекинга. При запущенном таймере каждые 10 минут система делает скриншот экрана. Не оставляя удаленным сотрудникам возможности смотреть сериалы и заниматься чем-то кроме рабочих задач, за которые компания и платит деньги.

Система мотивации исполнителей состоит из 3 частей:

  • фиксированный оклад,

  • премиальная ставка часа.

  • премия за соблюдение стандартов качества,

Мы в RocketSales платим высокую премиальную ставку, сотрудник получает дополнительную премию, в момент закрытия задачи. Но мы зорко следим за эффективностью выполнения задач и нацелены на максимальное качество за отработанное сотрудниками время.

В RocketSales есть интеграция Asana и Time Doctor. Сконцентрируйтесь на черной плашке в центре изображения. В нашей Asana есть масса интересного, например, разноцветные плашки оценки каждой задачи в часах/прибыльности/приоритете. Но сейчас фокус на черную плашку в центре.

Сквозная интеграция обеспечивается расширением для Google Chrome, которое позволяет видеть текущую стоимость, состояние проекта (общий срок реализации, когда и кто работал последний раз, сколько времени потрачено).

Технически задача сперва создается в Asana, потом прокидывается в TimeDoctor, а затем из TimeDoctor в Asana подгружается статистика по списанному на задачу времени.

И как это все объединяет ERP-система?

ERP работает независимо от других сервисов компании, туда проект попадает в виде карточки. Все задачи в проекте отображаются списком.

По каждому активному проекту компании мы видим:

  • Статус сделки

  • Тип сделки (по типу работ)

  • Задействованные участники

  • Кто трекал (списывал) время в этот проект

  • Общий бюджет проекта

  • Общая премия, сколько получит каждый сотрудник после закрытия этого проекта

Наша ERP - источник постоянных инсайтов для руководителей.

Они осуществляют контроль качества и решают, какие задачи можно считать закрытыми. Эффективность сотрудников для них очевидна, не нужно строить догадки, нет никаких интриг, понятно, кто и как работает.

Интересное наблюдение, что ответственные и эффективные сотрудники никогда не переживают из-за такой прозрачности в работе. Их не заботит факт, что система делает скриншоты, отправляет руководителям отчеты о начале и окончании их рабочего дня. Им нечего скрывать, они уверены, что оправдают ожидания.

Если сотрудник возмущается, он, как правило, лодырь и бездельник.

В общей карте проектов скрыт еще больший функционал: я, как руководитель, могу провалиться в проект в ERP и отследить активность касаний с проектом.

Вверху - графики активности.

Ниже информация, сгруппированная по дням работы над проектом.

Один из важных плюсов - сквозная интеграция всех систем. Я могу в один клик перемещаться из ERP в Asana, amoCRM, в нашу B2B (в ней мы управляем готовыми решениями для amoCRM, модулями, виджетами, конкретными интеграциями к аккаунтам клиентов). И обратно. Везде есть обратные ссылки на источник данных.

Какие данные доступны в ERP

Начать надо с того, что доступы у всех разные. Линейные сотрудники видят 1/10 дашбордов руководителей. Но, раз мы говорим про управление компанией, буду рассказывать про максимум.

Рабочий стол - это метрики по сотруднику

Во сколько он обходится компании, сколько часов отработал, над какими проектами работал за неделю, месяц, год.

Клиенты - дублированная база всех, с кем мы работали

Прямо из нее можно переходить в конкретные сделки в amoCRM. В целом эта база дает нам больше возможностей для сегментации, аналитики, построения долгосрочных отношений с клиентами.

Проекты - общий список всех проектов в производстве

Общий обзор проектов компании, есть фильтры по названию, клиенту, менеджеру, типам работ, необходимым статусам, плановым датам. Полагаю, в некоторых сферах это будет полезно.

Есть аналогичная вкладка по всем задачам с такими же возможности фильтрации.

Бухгалтерия - все закрывающие документы по проектам

Управленческий инструмент для главного бухгалтера RocketSales. Здесь хранятся все счета, акты, закрывающие документы и договора.

Список сотрудников компании

Вся команда с должностями, ролями, контактными данными.

Отчёты - самая ценная вкладка для управления компанией

Отчет по проектам

Статус сделки, участники проекта, бюджет на проект, количество отработанных часов и сроки.

Отчет по сотрудникам

Когда работал последний раз, над чем работал последний раз, во сколько начал день, сколько часов отработал на неделе, за месяц, в прошлом месяце.

Отчет по клиентам

Сколько времени команды уже ушло на работу с клиентом, какова себестоимость проектов.

Отчет по зарплате и премии

Руководителю эти отчеты дают абсолютную прозрачность для управления ресурсами команды.

Сотруднику они дают объективную аналитику собственной эффективности и возможность в режиме онлайн отслеживать объем заработной платы.

Отчет по конкретному сотруднику за июнь.

Любой день можно развернуть и увидеть поминутную занятость.

Чего нам стоила и стоит такая разработка

Нашей ERP-системе 2 полных года. На ее разработку мы потратили 2 490 часов сотрудников (топ-менеджмент, менеджеры проектов, собственник, сама разработка, тестирование, отладка).

Все данные мы храним, логируем, синхронизируем на собственном сервере. Обновление данных происходит раз в 5 минут.

Чтобы поддерживать такую ERP-систему нужны ресурсы:

  • активные пользователи, которые дают user experience, говорят, что работает плохо, а что хорошо;

  • поддержка технической исправности системы. Неизбежно возникают ошибки, мы фиксируем их в Asana и устраняем в рамках техподдержки;

  • стратегическая команда, которая анализирует необходимость данных и отвечает за развитие системы. Процессы компании меняются, часть возможностей ERP потеряла смысл, но возникла потребность в других возможностях. Собственник, топ-менеджеры, маркетологи нашей команды системно работают над картой развития нашей ERP.

Краткий обзор нашей ERP-системы мы делали в рамках первого занятия курса по внедрению Asana. В этом видео вообще есть довольно глубокий анализ всех инструментов, которые мы используем в бизнесе.

Для чего я вам все это рассказываю

Чтобы поделиться опытом и показать, как это работает у нас. Честно говоря, после такого подхода к управлению на основе показателей, нам тревожно за команды, которые никак не учитывают ресурсы.

Потому что самое дорогое в компании - время сотрудников.

Потому что каждый в команде может увеличить свою эффективность только имея представление о текущей продуктивности своей работы.

Потому что руководитель может спланировать загрузку сотрудников, только если видит сколько и на что у них уходит времени.

А еще с нашей ERP-системой мы без проблем перевели 40 человек из офиса на удаленку. Вопросов к сотрудникам не возникало, потому что мы в любой момент могли посмотреть, кто чем занимался и каких результатов достиг.

Хорошая история с прозрачностью в подсчете зарплаты. Никаких интриг и неприятных сюрпризов. Все цифры публикуются со ссылкой на источник. Премии считает система, ориентируясь на количество и сложность закрытых задач. А не руководитель, ориентируясь на личные ощущения и свое усмотрение.

В общем, я убежден, что затраты на внедрение ERP-системы - это не расходы, а инвестиция. Увидев эффект от внедрения мы еще больше доработали нашу Asana, стали много экспериментировать в CRM, делать маркетинговых ботов.

Конечно, такая ERP нужна не всем. Я считаю, в IT нет универсальных решений, которые можно штамповать не глядя. Но об учете ресурсов точно стоит задуматься каждой компании. Что вы думаете на этот счет? Стали бы так заморачиваться?

Подробнее..

Золотое кольцо скучнейших экскурсий как это пытаются исправить

10.09.2020 14:18:39 | Автор: admin
Привет! Мы сейчас всерьёз упарываемся по развитию внутреннего туризма. Обычно я пишу про эту часть работы не на Хабр, но на днях появился один крутой пример, по которому можно отследить интересное продуктовое мышление и UX-подход. В реальном мире. В общем, компания внезапно поняла, что мир изменился, старые подходы не работают, и вообще-то вокруг есть много крутых технологий. Меня позвали как эксперта всё это оценивать и тестировать раннюю альфу турпродукта, и я просто хочу показать, как рациональное мышление может повлиять на туризм.

Итак, у нас есть экскурсии по Золотому кольцу России. Для пенсионеров это желанное приключение, для молодёжи особый подвид предельно скучного и бессмысленного занятия. 20 храмов за 3 дня, Самые нудные экскурсоводы, сыпящие датами, Очереди в банальных местах вроде заселения в отель это из отзывов. Думаю, вы и сами можете себе всё это представить.


Вот так должно выглядеть заселение в отель: без людей и анкет, чёрт побери!

Первый вопрос к любой деятельности это зачем она делается. Обычно после грамотных ответов процентов 20 проектов в компании можно закрывать, потому что они плюс-минус бессмысленны. Второй вопрос как всё декомпозировать и переделать каждый кусочек в соответствии с целью.

В примере подошли немного иначе: переписали всё, что бесит, и просто начали думать, как это убрать. Подход, очень знакомый мне по рознице это способ резко поднять уровень сервиса до небывалых высот. Давайте пройдёмся по тому, что конкретно сделали в этом примере.


Пробки на выезде из Москвы


Туроператор Анкор делает туры с 96-го года. Сначала была Европа, в какой-то момент добавилась Россия. Наш маршрут Золотое кольцо. Цель альфа и бета-тесты с группой экспертов. Сюрпризы пошли сразу: мы выехали утром понедельника. Большинство тургрупп отправляется на выходных, как раз тогда, когда народ едет в этом направлении на дачу, а возвращается вместе с теми, кто едет на работу. Это даёт примерно 2 часа потерь в первый же день.

И вот всего 50 лет туризма нужно, чтобы понять, что начать отправляться можно в понедельник.

Почему так? Потому что большинство туров по кольцу это туры выходного дня плюс пара будних. Но, внезапно, туристы могут выезжать и без привязки к выходным. Этот тур спланирован как модуль группы развлечений, чтобы туристы (в том числе иностранные) могли гулять по Москве на выходных. Программа такая: приехали в пятницу, погуляли по городу, осмотрели фрагмент Ленина и выставку достижений китайского хозяйства, а на будние взяли Золотое кольцо. По будням свободнее отели, рестораны, нет очередей на входах в кремли и нет пробок. Логистика становится предсказуемее, и можно закладывать меньшие интервалы на если застрянем. Это значит, что будет меньше скучных историй, когда приехали раньше и нужно тянуть полчаса.


Если вы забыли дома компас и карту, то отличить границу Московской области можно по торговым автоматам

Ужимание гида


Одна из самых страшных историй это когда гид на Золотом кольце на полном серьёзе намерен прочитать двухчасовую карательную экскурсию. В нашем эксперименте Анкор попросил гидов на каждой точке читать сокращённые версии экскурсий.

Например, на комплекс в Суздале было заложено 2 часа, а надо уложиться в час. Золотая кладовая 15 минут, показать, что она есть, дать сделать фото, подсветить 3 главных объекта. Колокола показать, что они звенят и сказать, как сложно это всё, показать звонаря за работой. Тюрьма показать, что там сидели немцы (важно для иностранных групп) и пару камер. Архитектура и огород ещё 15 минут.

Результат получился странный. Никто вообще не поменял программу. Часть гидов просто игнорировала на тайминги (Ну как так-то, экскурсию же надо рассказать), а потом обижалась на то, что мы не идём в ещё какую-то часть комплекса. Другая часть поняла про тайминги, но не поняла про контент, и просто говорила в два раза быстрее. Что довольно страшно вообще-то, особенно, когда тебя засыпают датами. Меня особенно поразила экскурсия в Ярославле, где гид до кучи не ответила ни на один вопрос (это будет дальше по экскурсии, не отвлекайте).


Рассказывать 18 минут про одно украшение? Подержи моё пиво!

Ещё одна проблема то, что гиды во многих городах любят деньги больше, чем впечатления туристов, и не дают приезжим проводить экскурсии по своим комплексам. То есть нужно привезти им туристов, отдать гиду на месте деньги, и он сделает экскурсию. Схема отдать деньги юрлицу и провести свою экскурсию тоже не работает, только местный гид, только хардкор. Просто не пускают на территорию комплекса не своих, не дают вести экскурсии, не сертифицируют и вообще мешают организационно.

Как вы, возможно, знаете, это сейчас успешно решается IZI travel и другими аудиогидами, просто напрочь выбрасывающими местных гидов с рынка. К сожалению, в том же IZI при прекрасных экскурсиях по Европе и всяким окраинам есть невероятное количество той же залепухи с мешаниной дат и имён всех отпрысков царя, что и в речи официальных гидов. С прекрасными интонациями моей школьной учительницы по литературе, которая надолго привила ненавсить к русской классике ученикам.

В итоге Анкор решил переходить на масс-персонализацию с помощью мобильного приложения для группы. Но сначала надо поговорить о том, что группы планируются мультиязычные.

Мультиязычные группы


Аудиогид не привязан к языку. С коллективом из русских туристов может поехать пожилая пара немцев, американец, четверо французов и молчаливый японец. Это решает сразу огромное количество проблем от раннего бронирования (критичного для Европы у нас не каждый оператор может обеспечить выезд в нужные даты, если предупредить за полгода) до контента. Иностранцы хотят общаться с настоящими русскими жителями, и для них это очень ценно. Это мы знаем по опыту Транссиба, когда самое большое счастье сутки ехать в плацкарте с мужиками в пижамах (на самом деле, майках-алкоголичках до колен), не знающими языка, но старающимися дружить. Как умеют. Кончается, конечно, катастрофически, но всем нравится.

Нашим тоже интересно, как японец откроет бутылку казацкой шашкой (похожей на катану, точнее, пехотную саблю сингуто), на что похож вкус борща для французов, можно ли споить американца, и что немцы думают по поводу дороги от Гаврилова Посада до Иваново.

В общем, впечатления на каждом шагу просто из взаимодействия с окружающим миром. Русский, немец и поляк пошли как-то в баню.... Единственный момент в том, что иностранцы обычно хотят как минимум один рынок и побольше русского быта. Быт здесь будет в общении с другой частью группы, а рынок будет сокращён до чего-то необычного ярмарочного, всё же нас развалами с рыбой удивить сложно.

В тестах мы тоже общались между собой потихоньку и узнавали новое. Владелец парка автобусов рассказал, как правильно сливать бензин при всех датчиках. Туроператор что было, когда в Италии ночью угнали автобус (группа не заметила). Гид как в Амстердаме купили групповые билеты на метро, а полицейский пытался разогнать экскурсию со словами демонстрации запрещены. Я знаю, что делают геологи, когда уходят в кусты пописать на трассе, а автобус уезжает. Узнал, что страховка не покрывает попадание в дурку в Европе, ну и услышал, как бабушка сдала в Лувре в сейф кастрюлю с тушёнкой.

Но, как вы понимаете, всё равно нужно что-то, что заменит гида.

Масс-персонализация


Это технология, когда продукт построен так, что кажется вам нежной ручной сборки, но на деле автоматизировано собран под вас. Первой ласточкой был Диснейленд ещё в аналоговый век.

Предполагается, что это будет приложение на терминале в автобусе или на телефоне туриста, которое умеет делать следующее:
  • Проигрывать аудиоблоки по несколько минут про то, что сейчас видит группа.
  • Запускаться от координат или от команды гида (гид предлагает перейти к такому-то фрагменту).
  • Трекать гида, автобус и туалеты на карте и отвечать на запрос координат (гид просит отправить геопозицию, да/нет).
  • Показывать разные вспомогательные вещи вроде карты кремлей, калькулятора валют, адреса отеля, программы на день и так далее.

Интересное, конечно, с блоками гида. Во-первых, весь маршрут нужно декомопзировать на блоки по 3-5 минут. Во-вторых, каждый блок нужно не только перевести, но локализовать. Когда мы говорим про квас, всем всё понятно. А вот японцу нужно будет пояснить, что такое этот русский хлебный перебродивший сок. Опять же, нам, возможно, интересно, какая связь между Киевом и Москвой через исторического персонажа, а вот иностранцам пофиг то есть каждый кусок подаётся с учётом специфики. Предполагается, что модуль делится на ядро (что нужно точно рассказывать) и локаль-часть (обычно около 15% дополнений).

Тематические блоки тоже варьируются. Понимание региона отличается для разных локалей, в каждом регионе подсвечивается одна из ценностей или особенностей, объясняется культура. То есть к моменту приезда в город какой-то фон уже есть. Самое сложное музеи из большого объёма сделать главное и интересное.

Как вы понимаете, доведенная до ума такая схема в целом позволит не только избавиться от местных скучных гидов, но и тестировать каждую экскурсию по интересности по каждому блоку. А, ну и да, снять человеческий фактор вместо гида будет робот. А сам сопровождающий сосредоточится на решении проблем туристов.

Итого этот план позволит и выравнивать загрузку, и добавлять приключений между иностранцами и россиянами и вообще звучит круто. Но остро нуждается в тестах. Пока эта часть для туркомпании самая сложная, потому что, очевидно, они не разработчики.

Автобус с розетками и большим расстоянием между креслами


Люди живут с гаджетами, и поэтому на каждом пассажирском сидении автобусов оператора есть USB-розетки. Поскольку планируется делать мобильное приложение с языковыми версиями, так и так электросеть нужна либо под терминалы, либо под зарядки. Вайфая нет, но почти везде по пути (за исключением пары мест по 20 км между городами) есть хорошее сотовое покрытие.


Большое расстояние между креслами = спинка нормально откидывается. Вторая кнопка сбоку сдвиг на 6 см в сторону прохода.

Заселение до экскурсий


Канонический путь ушатать группу вусмерть пятью экскурсиями, а потом привезти в отель и заселить вечером. Чтобы спали ровно и не выделялись по городу. Селить днём почти нельзя: ведь туристов водят по музеям, а музеи в регионах закрываются рано, обычно 17:00, максимум 18:00.

Наши протагонисты выбрали другой подход: заселение обычно сразу после переезда (то есть днём), а после обзорная экскурсия по очередному городу и ужин в ресторане. То есть люди могут бросить часть вещей, переодеться под погоду в городе, принять душ, что-то поставить на зарядку и так далее. Обычно на заселение примерно минут 20-25 до обеда, и этого времени хватает. В тестах было видно, что люди, в целом, не склонны пропускать обеды, поэтому на следующую экскурсию никого ждать не приходится.

Классическое заселение выглядит как верх идиотизма бронирование идёт с копией паспорта, а потом туристы встают на стойке в очередь на получение ключей и проходят стандартные процедуры: заполнение анкеты, ксерокопия первой страницы паспорта, получение ключа. Да, это по полторы минуты на номер, но при группе 20 человек уже проблема. Что характерно, никто не задумывается, что примерно половина действий бессмысленна.

Сканы паспортов можно взять из почты и распечатать они отправляются при бронировании. Ключи можно разложить на стойке и подписать фамилиями туристов пусть расхватывают сами. Анкету можно давать либо при выселении, либо положить в номер и попросить заполнить к выселению.

Анкор проинструктировал отели по дороге сделать именно так. Для двух даже при наличии подробного объяснения, как улучшить процесс, это оказалось шоком. И сделать правильно они не смогли. Я ни разу не удивлён, потому что вижу такое почти в каждой стране. Но всё же один раз получилось на 100% правильно.

Отдельно стоит сказать про выбор отеля. Как в путешествиях по миру ты никогда не угадаешь, как именно работает кран в душе, так и в наших отелях самый первый квест найти розетку. На Золотом кольце ныкание розеток выделяется особой изобретательностью: я видел и всего одну в комнате для холодильника, задвинутую столом; и подключенную прямо в линию подложку для чайника без розетки; и единственную розетку около входа в номер, видимо, для обуви. К счастью, наконец-то нашлись люди, которые выбирают отели в том числе по одному из весовых коэффициентов удобная розетка.

Правильная еда


Знаете, что иностранцы говорят в Ярославле, когда идут обедать? Опять этот красный суп!. Потому что на Золотом кольце каждый ресторан старается удивить традиционной русской кухней. В итоге у нас на первое всегда борщ, на второе всегда картошка с мясом в разных формах, салат селёдка под шубой, а десерт водка. Три раза в день каждый день в разных местах.

Надо сказать, что рестораны почувствовали это по отзывам и начали менять предложение. Кто-то уходит во фьюжн-кухню, кто-то пытается играть компонентами и так далее. Получаются знакомые блюда, приготовленные так, что их хочется пробовать. Ну, знаете, разница между классической перловой кашей и вот этим с куриными сердечками как между Терминатором и Терминатором 2:



А так надо просто заказывать разные блюда, а не отдавать выбор на откуп заведению с их набор еды туристу 1.

Завтрак: когда в отеле большой поток туристов, то обычно есть шведский стол, и это устраивает всех без исключения. Я сейчас не говорю про финский шведский стол, означающий можешь выбрать из супа и трёх видов сухарей, но пополнять тарелку можно сколько угодно. У нас ещё до такого не дошли, к счастью. Когда поток поменьше, либо оператор ужимает бюджет, накрывается комплексный завтрак, состоящий из реальной каши с хлебом и мнимой части. Так вот, группам нужен континентальный завтрак, если он порционный потому что наши любят поесть, а иностранцы должны чувствовать, что русские пытаются убить их едой. Это называется гостеприимство.

Обед и ужин на турпрограмме важны не только едой, но и сервировкой. Люди вообще-то ездят переключать картинку и вырываться из обычной рутины, и часть впечатления чтобы всё было похоже на праздник. Обедать в столовой даже на Золотом кольце не круто.

Ещё фиксы


Организатору до выезда нужно рассчитать график туалетов и проверить их. Если на точке с санузлом проблема (он создаёт бутылочное горлышко, он создаёт неизгладимое впечатление и т.п.), то в этом месте экскурсии не будет, либо она будет очень короткой, в районе 15 минут. Подводить иностранцев к дырке в полу вообще очень интересно для погружения в атмосферу Древней Руси, но цель не в этом. Как мне кажется, причинять душевные страдания это всё-таки принцип оказания государственных услуг (почти в любой стране), а не коммерческих.

Потом язык гида: предполагается максимально простой. Сейчас уже спам-маркерами считаются причастные обороты, больше трёх дат на блок и так далее. Сейчас уже обкатываются в тестах фрагменты для Золотого и Усадебного колец. В общем, верной дорогой идут товарищи.

В ходе тестов кто-то из экспертов отметил, что 56% впечатлений от экскурсовода складывается по тембру голоса. То есть в отзывах бывает он заботливый, добрый, но поменяйте, голос с нотками визга пенопласта по стеклу. Точнее, обычно это сформулировать не получается, но людей бесит. Ещё нужно в аудиоблоках постоянно чередовать женский и мужской голоса, чтобы было оживлённее.



Что интересно, ещё подход с приложением и языковыми блоками открывает турпродукт интровертам. Сейчас эта аудитория очень сильно недооценена из-за того, что нормальный интроверт просто не поедет в автобусе с очень высокой вероятностью. Кстати, потому, что нужно ходить за гидом и ловить его слова, что очень напрягает на экскурсиях. В рамках теста мы ходили с радиогидами (не было записанных блоков, но гид давала тот же материал в канал), что оказалось очень крутым. Ощущение почти как от самостоятельной поездки даже если ты через два квартала от группы рассматриваешь отличного мутольва в узоре на стене, можно услышать про то, что монголы вовсе не при делах при сожжении Суздальского кремля. Кстати, наш гид рассказывала, что в автобусах есть штатная переключалка на радиомикрофон, но её мало кто использует. Как-то благодаря этому её экскурсия транслировалась на 17 автобусов на площади.

В общем, получается довольно интересно под нишевую аудиторию. Продукт чуть дороже обычного, но заплатить 5-7% сверху за то, чтобы не вспоминать детскую травму от советского экскурсовода такие люди есть. Собственно, я очень хорошо знаю из своих исследований, что около 18% людей считают вообще любые путешествия по России унылыми. Тут надо сказать, что Анкор вообще-то уже доказал, что умеет раскрывать нишу до целого рынка. В 96-м году они возили в Париж и Рим, тогда запрос был на 5 стран за неделю на автобусе. Потом появился неожиданный запрос на комфорт: стали стыковать самолёт в Европу и автобус на месте, а для иностранцев чтобы в России была ночь в поезде. Для немцев, например, это дико прикольно, потому что поезд просто не может столько ехать, чтобы там спать. Потом запрос наших туристов эволюционировал на тематические экскурсии, и Анкор стал возить своих гидов (получалось дешевле, чем нанимать на месте). Уже где-то в 2005 стало важно переходить к качественному контенту внутри тура: чтобы и отдых, и изыски, и тематичность. Уровень гидов менялся: нужен был не только знаток, но и психолог, понимающий, какая тактическая обстановка в автобусе. Кроме выбора темы ещё важно делать так, чтобы хотя бы 15-20% подаваемой информации человеку были знакомы и понятны, иначе будет отторжение. На Золотом кольце, к слову, такой информации должно быть до 25-30%, иначе люди будут думать, что вообще не знают своей страны, а это портит настроение и порождает небольшой комплекс неполноценности. Человек должен чувствовать себя комфортно, потребляя информацию. Это тоже важный тренд.

Первые технологии для кольца были отработаны с немцами, которые давно возили по Европе своих туристов. Отсюда появилось бронирование места в автобусе при покупке тура (для некоторых это очень важно). Немцы проходили десятилетия назад те же проблемы, что у нас сейчас: хороших экскурсоводов мало, наушники никто брать не хочет (А что, я так расскажу! у нас в тестах 4 гида просто отказались работать с техникой). Нет элементарного понимания физиологии людей (или уважения к группе). У региональных гидов часто есть склонность заставлять людей страдать у памятника, пока идёт рассказ сколько метров и сколько кирпичей потрачено. Да, дождь, да, град, да, дует ветер, но туристы же заплатили! Получение информации это труд, вот и пускай отработают! То же самое можно рассказать в автобусе заранее. А если гид умный то не рассказать, а сделать интерактивно, предложить прикинуть высоту заранее, угадать, сколько оно весит. Очень многое из того, что рассказывают про гидов бьётся с тем, как вообще нужно подавать научпоп-информацию. Это безумно интересно, и я про это тоже расскажу чуть позже, когда систематизирую опыт ещё пары человек.



Получается?


Мне понравился подход. Иру (руководителя проекта) многие в туризме не понимают, а в регионах так вообще при попытке переформулировать из здесь вы можете прикоснуться к уникальной атмосфере Древней Руси и ощутить дух времени в Смотрите, какой крутой храм, тут льва на стене нарисовали по словесному описанию, вот он чуть ли не поднимают на вилы со словами: Да как вы смеете, вы ничего не понимаете в туризме!. Правильно, потому что кое-кто учился 5 лет, а потом 10 лет стажировался, чтобы сейчас вылетать с рынка. Ещё суеверный ужас вызывают такие ходы как проезд города насквозь с остановкой на один музей (привет, Иваново, пока Иваново!), исключение всяких значимых мест типа ещё 10 храмов в программе и так далее.


Вот это незаконно, точнее, это объявление касается только для персонала объекта


А вот это неожиданно

Но где-то воспринимают нормально и даже хорошо. Потому что понимают, что теперь рынку нужно другое. Возможно, потому что видели результаты наших исследований, что только 3% жителей Европы готовы поехать в Россию. Потому что невидимая рука рынка показывает тем, кто не меняется, невидимую фигу. В этом плане мне особенно нравится история с краеведческим музеем в Иваново. Там была старая история про то, что в музее живёт привидение. То кошки на него реагировали, то его кто-то видел. В общем, вопрос закрыли установкой датчиков движения и камер. Привидение перестало проявляться. Музей не растерялся и сделал регулярные ночные экскурсии по тёмному музею с фонариками под рассказы про несчастного духа. А за группой на границе света крадётся младший научный сотрудник в костюме.

С другой стороны, в каждом городе всё ещё есть фильм, рассказами про который тебя задолбают. При посещении некоторых храмов группа всё ещё обязана зайти в конце на 10 минут в церковную лавку, иначе на территорию не пускают. Даже платный корм для уточек может оказаться в другом конце кремля задолго после самих уточек. Уровень сервиса почти везде просто потрясает своей ужасностью (а я знаю, о чём говорю после 10 лет розницы-то), и исправляться это будет с трудом, потом и соплями. В общем, если бы не закрытие международки, то многие эксперты в жизни не поехали бы по Золотому кольцу. А так получилось не только показать первые изменения, но и подсветить многие города. Я хочу вернуться в Кострому за лосиной фермой, в Гаврилов посад за музеем русских напитков и конезаводом, в Иваново ради конструктивизма, а в Суздаль просто погулять.



С нами были здравый смысл и Ира Маштакова, директор туроператора Анкор. Надеюсь, в итоге с продуктом всё получится.
Подробнее..

Архитектура Пизанской башни

11.09.2020 20:19:02 | Автор: admin
Всем привет. Находясь на удаленке дома, сложно не вспоминать о прошлых путешествиях и не уйти в философию. Своими размышлениями делюсь в преддверии курса Agile Project Manager, в создании которого участвовал.





Конец сентября, Пиза, 7 лет назад. Экскурсовод-итальянец перед восхождением на Пизанскую башню с гордостью рассказывает туристам краткую предысторию: башня возводилась в несколько этапов, была завершена почти через 200 лет после начала строительства, и уже на первом этапе был обнаружен крен из-за слишком мягких грунтов под фундаментом С этого момента начинаю слушать внимательней: оказывается, архитекторы башни не решились отдать голову на отсечение и отказаться от дальнейшего возведения, зато последовательно работали над балансировкой сооружения десятилетиями. Благодаря этому, а также определенным усилиям наших современников, мы имеем возможность не только лицезреть, но и посещать поистине выдающийся архитектурный памятник.

Меня впечатляют сроки проектов того уже сравнительно просвещенного времени. Однако в нынешнем бизнес-мире мало кому захочется повторить такой подвиг строить веками ни современники, ни тем более потомки его не оценят. Но можно заметить, сохраняя аналогию со строительством и на порядки ускорив время, что зачастую разработка архитектуры нынешних организаций напоминает балансировку строящейся и одновременно падающей башни. При этом дуют сильные ветра, регулярно происходят землетрясения, а жильцы уже въехали и активно занимаются перепланировкой. Было бы здорово сделать башню лёгкой и упругой, чтобы она не ломалась, а невзначай упав, возвращалась назад, как неваляшка. Но чем выше мы поднимаемся, тем быстрее мы строим, чем больше внимания уделяем верхушке и красивой отделке, тем тяжелее она становится и грозит обрушить всю башню даже при небольшом наклоне.

Аналогично, последние годы современное профессиональное сообщество прилагает максимум усилий, убеждая окружающих и самих себя, в непрерывности рождения нового. Не спорю, технологии эволюционируют, а светлые головы рождают инновационные идеи. Но желающих приобщиться (заработать) намного больше: вспомним, как несколько лет подряд партнеры международных консалтинговых компаний в дорогих костюмах перемещались из кабинета в кабинет с предложением юберизовать ваш бизнес, ориентируясь на уважаемого за технологичность, но убыточного агрегатора, по сути, без материальных активов. За ними следующими шли энергичные ребята в футболках, обещая сначала реализовать любой каприз на блокчейн, потом сократить половину сотрудников благодаря ИИ, и так до бесконечности. Приглядевшись можно заметить, что старые бизнес-модели в большинстве своём никуда не исчезают, а скорее переизобретаются и скрываются под новой терминологией. Из широко известных, действительно, выглядит актуальной платформенная модель, которая тоже в общем-то не на пустом месте появилась. Она требует значительных инвестиций, зато при успешном воплощении, даёт прирост эффективности и потенциал по доле рынка.

Чаще всё сводится к улучшению упаковки (ой, извините клиентского опыта), чтобы ручеек потребительского спроса менял своё русло в желаемую сторону. Это суррогат. В реальности, если я захочу индивидуальный клиентский опыт, мне придётся стать очень богатым. А если я, допустим, попрошу встроить в мой автомобиль простенький автопилот не по цене нового авто, а по цене хорошего гаджета, то не выйдет без замены платформы, не предусмотрено и всё тут. С одной стороны, нас подталкивают к смене автомобилей с той же регулярностью, что и смартфонов, но этот вопрос больше про социум и экологию. С другой стороны, как только мы касаемся архитектуры, легко поменять на лету уже не получается. К примеру, стратегические цели компании обновляются регулярно, и намного чаще, чем архитектурные принципы, призванные обеспечивать выполнение долгосрочной стратегии (при условии её наличия).

Поделится ли кто-нибудь успешным опытом внедрения нового бизнес-процесса сразу на десятки тысяч клиентов и сотни сотрудников, в режиме двухнедельных спринтов? Кто-то скажет, легко это по agile. Но я не про разработку интерфейсов, не про добавление бизнес-правил, не про A/B-тестирование, а непосредственно про релиз процесса с нуля и мы обнаруживаем, что платформу сложно создать по Scrum, но последнему надо обеспечить нормальное функционирование в прикладных сферах. Платформа не состоит из одних пользовательских историй примерно также, как успех онлайн ритейла не так сильно зависит от веб-сайта. Параллельно представим пример из другой сферы: на сколько сильно обрадуются CEO или CFO рекомендациям списать лишнее оборудование и арендовать место в новом дата-центре с созданием гибридного облака. Почему вы не подумали об этом раньше, обязательно спросят они с серьезным видом. В итоге, конечно, нужна инфраструктура-по-запросу, но затраты на такой сервис будут зависеть от нашей предусмотрительности.

Суммирую размышления: целью корпоративного архитектора, совместно с другими лидерами трансформации, является долгосрочное обеспечение необходимой и предсказуемой гибкости для детального проектирования и последующих непрерывных улучшений на фоне обеспечения устойчивости конструкции в целом. Данная парадигма не претерпела существенных изменений за десятилетия, только мотивация выражалась другими словами и потребность в гибкости не всегда была столь очевидна. Поэтому модный термин agile-архитектура звучит курьёзно, а вот архитектура гибкой организации вполне уместно.

Сейчас нам открыты реальные способы сделать организацию в целом более гибкой и это важнее и сложнее, чем поддержать гибкость технически и организовать соответствующий цикл разработки, благодаря микросервисам, контейнерам, непрерывной сборке и т.д. Как минимум, лидерам программ трансформации и портфелей проектов нужно принять тот факт, что внутри исполнения их планов команды будут применять гибкие методологии, и надо суметь оставить для них достаточно пространства. Но больших успехов можно добиться, кардинально пересмотрев организационно-функциональную структуру компании и модель управления. При этом, гибкость должна находиться в очерченных допустимых границах, определяемых стратегией инвестиций, целями портфелей и дорожными картами программ. Тогда маловероятно, что здание бизнеса компании внезапно начнёт валиться, и его придется много месяцев подправлять и балансировать. Определение правильного сочетания гибкости и устойчивости вполне решаемая задача.


Читать ещё:


Подробнее..

Из песочницы Пользовательские истории это не требования

13.09.2020 16:10:25 | Автор: admin
Привет, Хабр! Представляю вашему вниманию перевод статьи User stories are not requirements автора Пер Лундхольм (Per Lundholm).

Слоны не жирафы, а пользовательские истории это не требования. Они имеют и общие черты и общий контекст, однако это не ставит между ними знак равенства. Тем не менее, многие полагают, что пользовательские истории являются своего рода новым прочтением того, что традиционно называется требованиями к программному обеспечению ведь, должны же быть требования на проекте, правильно? Так вот, я отвечу нет, и еще раз нет. Во первых, это не требования, во вторых, требования это не то, что нам на самом деле нужно. Пользовательские истории это прежде всего шанс увидеть различные варианты реализации, чтобы потом можно было воспользоваться открывшимися возможностями. А требования это решить все наперед, чтобы потом в этом увязнуть.


А есть ли вообще смысл в написании подобной статьи? Разве сказанное выше не кажется очевидным? Нет, я полагаю, что нередко встречающиеся высказывания типа требования в бэклоге сигнализируют о том, что парадигма мышления осталась старой, просто вывески поменялись. Документ требований стали называть бэклогом, сами требования пользовательскими историями, и вот мы уже agile

Еще один признак возможного недопонимания распространенная практика сохранения пользовательских историй в БД с присвоением уникального ID. Вполне возможно, так делается просто ради удобства, но не исключено, что это результат проявления устойчивой тенденции думать в терминах требований.

А вот практика включения пользовательских историй в контракт это уже стопроцентный признак того, что пользовательские истории рассматриваются в качестве требований. Проблема здесь в том, что пользовательская история по определению не может быть такой однозначной, как требование, а это обесценивает контракт. Безусловно, требования иногда тоже можно достаточно свободно интерпретировать, но сама техника их написания изначально подразумевают устранение двусмысленности, чего не скажешь о пользовательских историях. Кроме того, требования устойчивы к изменениям, поскольку они входят в проектные контракты. Для того, чтобы изменить или добавить новые требования, их нужно провести через CCB. Другими словами, заинтересованные лица должны их сначала согласовать и одобрить. Подробнее о контрактах см. ниже.

Так что же такое пользовательские истории? Рассматривайте их, как инструмент планирования. С помощью пользовательских историй мы определяем приоритеты, оцениваем и принимаем решение в каком спринте будет реализована соответствующая функциональность. Все это типичные признаки инструмента планирования, поэтому не стоит пытаться превратить их во что-то другое.

Сила пользовательских историй в том, что они дают начало диалогу. Вместо того, чтобы просто взять и передать коллегам спецификацию, которая интерпретируется сначала разработчиками, потом тестировщиками мы начинаем обсуждение. Мы включаем в коммуникацию сотрудников с различными навыками. И так по каждой новой фиче.

Поскольку пользовательская история, как таковая, не несет в себе много смысла, мы можем просто отбросить ее по факту реализации соответствующей функциональности. При желании можно тщательно вести статистику количества реализованных историй, но этим вполне можно и ограничиться.

Получается, что требования нам не нужны? На самом деле это не совсем так. Ведь, так или иначе существуют ограничения. Например, медицинское оборудование обязательно должно соответствовать правилам FDA. Так давайте тогда и будем называть их ограничениями!

И все же, требования детально описывают Систему, возможно, в подобном описании есть какая-то ценность для нас? К примеру, как определить является ли некоторое поведение системы багом или нет, если у нас отсутствуют представленные в том или ином виде формальные требования? Здесь нам поможет техника Specification by Example. Итак, принято решение, что некоторая функциональность должна быть реализована. Вы пишите бизнес правила и серию примеров в таком виде, чтобы это было: а) удобно для восприятия; б) реализуемо. Из данного описания должно быть понятно, что должна делать Система. А так же, если что то пойдет нет так вследствие внесения изменений нарушение какого бизнес правила явилось причиной данной дисфункции.

Как я писал ранее, описание бага должно быть простым и четким. Баги это нечто, разрушающее информацию, это то, что плохо независимо от того, есть ли у нас описание требования, покрывающее данный кейс, или его нет.

Контракт


(автор Маттиас Скарин)

Итак, что мы будем использовать вместо спецификации требований? Ведь нам нужно понимать реализовали ли мы именно то, что было нужно? Мы будем использовать agile контракты. Agile контракты это возможность увидеть лес за деревьями, они позволяют сфокусироваться на сути проекта и совместном достижении цели, реализация которой удовлетворит потребности пользователей.

Имейте ввиду, когда вы по ходу проекта вспомните о контракте с тем, чтобы проверить не нарушил ли что-нибудь ваш партнер, это уже означает, что что-то идет не так. Контракт должен укреплять доверие между сторонами, с тем, чтобы стало возможным выйти за рамки частностей, а не увязнуть в них.

Резюме


  • Несмотря на то, что и слон и жираф имеют по четыре ноги, это разные животные.
  • Пользовательские истории это не требования, а инструмент планирования.
  • Наиболее близкое к требованиям Specification by Example.
Подробнее..

Где клиника теряет деньги на каждом этапе плана лечения (и где воруют)

15.09.2020 10:12:59 | Автор: admin
Это пример автоматизации одного процесса в стоматологической клинике, который прямо влияет на результаты её работы. Итак, сначала нам звонит пациент. Это может быть как потенциальный пациент, у которого что-то болит, так и один из имеющихся пациентов, у которых есть план лечения в клинике. Вот так выглядит кол-центр. Как видите, номер не опознан, и мы сразу же можем его записать на первичный приём (это наиболее ожидаемое действие от неопознанного пациента):

image

Записываем в расписание. Сразу можем указать статус: VIP, ДМС. Можем записать как к одному врачу, так и к нескольким на комплексное обследование. Тогда он последовательно (профосмотр) или параллельно (терапевт + хирург, например) пройдёт обследование. Вот запись. Это выбор врача:

image

Приём первичная консультация. Без этого никак.

image

Можем изменить цвет записи и длительности приёма. По умолчанию всегда задан основной цвет и длительность на услугу. Но, если случай сложный или пациент особенный можно выделить это в расписании. Если же пациент повторный, то тут будут приёмы из плана лечения.

Всё, на этой стадии запись окончена. Теперь мы ждём, когда пациент придёт в клинику.

Возможные потери на этом этапе


  • Звонок нового пациента должен вести либо к записи на первичную диагностику, либо к отказу. Нельзя лечить пациентов без диагностики, потому что это просто недопустимо по стандарту, во-первых, и создаёт море для злоупотреблений, во-вторых. Тем не менее можно сразу записать пациента на диагностику и лечение по его наиболее вероятному диагнозу.
  • Если пациент уже имеющийся, и он хочет сдвинуть план лечения (например, уезжает в командировку), нужно сразу же передвинуть все его процедуры, которые расписаны на месяцы вперёд соответственно, чтобы потом не разбираться, почему он пришёл к ортодонту несанированным.
  • При сдвиге постоянного пациента нужно двигать не только ближайшие процедуры, а вообще все иначе потом окажется, что ему нужно приходить, а всё время врача занято. Постоянные пациенты получают долгие слоты задолго до приёма, чтобы их не заняли перворазники, иначе получится, что клиника подстраивает своих более ценных клиентов под менее ценных. Альтернатива либо в потере ценного пациента с некоторой вероятностью, либо в сдвиге первичного пациента на 15 минут. Естественно, второе выгоднее.
  • Пациента нужно обязательно прозвонить за сутки до его прихода в клинику. Если этого не делать, загрузка кресел сильно упадёт. Поэтому процедура записи сразу же создаёт задачу на прозвон этого клиента.

Ура, пациент пришёл в клинику


Для оформления посещения у нас есть бегунки. Это штрихкоды. Они клеятся или печатаются в полиграфическом центре на пластиковую карту и присваиваются пациенту на каждый визит. Не обязательно делать так, можно учитывать просто пациентов по фамилиям, и это тоже есть в функционале. Но система бегунков очень экономит время врача и защищает владельца от злоупотреблений в клинике.

image

Если пациент первичный, то перед тем как его принимать, мы предлагаем заполнить анкету. Она позволяет себя обезопасить, и это рекомендация юриста. Тут содержится информация об аллергии на препараты, давлении и т. п. Если у пациента есть какие-то проблемы, доктор на приёме получит предупреждение всплывающим окном.

Анкету можно заполнить через подключенный планшет или через раздел Информация о пациенте там со слов пациента заполняет администратор. Если есть свой шаблон анкеты, его можно загрузить на этапе внедрения. Если нет, то используется одна из типовых. Вообще, мы довольно часто привносим автоматизацию в клинику.

Как это происходит в планшете:

image

Далее считываем QR-код на планшете, который лежит на столе у администратора.

image

Пациент отдаёт анкету администратору. В системе отражается информация, что анкета заполнена:

image

Анкету нужно отправить на печать и подписать:

image

Дальше оформление пациента. Вот взрослый:

image

Если пациенту меньше 18, у пациента появляется значок ребёнка, и появляется поле с данными родителей.

image

Договор, уведомления о несоблюдении рекомендаций, согласие на оказание медицинских услуг и обработку персональных данных.

image

Каждому документу присваивается штрихкод, его можно отсканировать и проверить, что документы действительно распечатаны. На этом этапе можно выдать дисконтную карту и приложить документы от страховой компании.

Если у пациента острая боль, то можно отметить её, тогда система пропустит этот шаг и досрочно даст начать приём врача.

image

Какие потери возможны на этом этапе


  • У администратора в голове часто документы делятся на важные и неважные. К неважным часто относится согласие на врачебное вмешательство и согласие на сбор персональных данных. Увы, но даже пациенту с острой болью нужно подписать договор и эти два согласия в нём, чтобы врач смог работать. Это занимает около минуты, но пропускать это ни в коем случае нельзя. Как ни парадоксально, но иногда пациенты встают во время манипуляций и уходят, а потом апеллируют к тому, что врач полез железякой в рот без того, чтобы пациент это ему разрешал. И выигрывают суды. Никакие данные с камеры на стойке ничего не будут значить, если пациент не дал согласие на действия врача.
  • Если пациента отправили к врачу без документов, то это пациент Шрёдингера: он может попасть в выручку клиники, а может не попасть. Если пациент вылечен, но записей про него нет, то никто не помешает врачу купить расходники за свой счёт (это 14 % от стоимости приёма) и принести их наутро в клинику, плюс немного поделиться с администратором. Обычно это выглядит так: собственник клиники заходит в свой филиал, видит врача с пациентом в кресле, но не видит запись про такого пациента. Спрашивает, что это такое. Врач говорит: Больному плохо, острая боль, я оказываю помощь, сгиньте, пожалуйста. Как закончу оформим. Это может быть правдой. Или нет. В любом случае этого конкретного пациента они потом оформляют вместе с администратором. Сколько таких прошло неоформленными неизвестно. Поэтому если у вас больше одного филиала, то сразу лучше принять за практику, что пациент не может пройти дальше стойки, если ему не открыли приём и не завели его в систему.

Пациент у врача


Ассистент приносит бумаги или бегунок с регистратуры:

image

Если стоит показывать анкету по умолчанию у врача сразу всплывает анкета.

image

Врач может изменить время приёма и его описание, если администратор ошибся и записал его не на плановый приём, а на лечение.

image

Тут нужно проверить документы и дополнить своими: допсоглашение с описанием и стоимостью приёма, согласие на вмешательство, отказ от видов медицинских вмешательств.

image

Посмотреть другие приёмы пациента сегодня:
image

Если у пациента проблемы со здоровьем появляется всплывающее окно:

image

Дальше, собственно, можно начинать приём. Если у пациента есть снимок он будет сразу же показан. Первая задача доктора отметить проблемы в зубной формуле.

image

В верхней части указываются проблемы, в нижней решения:

image

В зависимости от части зуба, в которую нажмёт врач, система предлагает соответствующие проблемы.

image

image

Есть массовая выборка на случай проблем всей полости рта.

image

На зубной формуле отразится проблема пациента.

image

В решениях подтянется несколько вариантов на выбор.

image

Проблема решение:

image

Если в решениях задействовано другое отделение обязательно выбрать врача, чтобы план лечения сохранился. Это нужно, чтобы создался план лечения и приёмы записались. Врача потом можно заменить.

image

Планов можно создать сколько угодно. Можно создать новый, можно скопировать этот. Создание нескольких планов позволяет создать пациенту несколько наглядных планов с разной стоимостью и облегчить выбор. На создание трёх планов лечения уходит около минуты. Обычно, врач проводит осмотр, а ассистент заполняет зубную формулу.

Потери на этом этапе


  • Пациента надо диагностировать целиком. То, с чем он обратился, может быть не главной проблемой. Плюс у 99 % населения проблемы с зубами: что-то нужно долечивать, что-то предотвращать, где-то можно успеть с кариесом на другом зубе, пока он не сорвал ползуба, где-то можно предложить услуги ортодонта. Если пациента лечить по симптомам будет плохо и ему, и клинике. Поскольку осмотр целиком почти не отличается по длительности от осмотра конкретной проблемы, стандарт де-факто стоматологических клиник полная диагностика. Из этой диагностики строится план лечения и план приёмов.
  • План лечения опирается на диагностику. Если проблемы нет её нельзя лечить. Если проблема есть её нельзя лечить не по стандарту. Это автоматически означает, что все ДМС-процедуры будут применены в правильном порядке и в правильном ассортименте (что исключает неприятные ревизии в конце месяца, когда нужно проверять каждую карточку на соответствие требований страховой перед подачей счёта за ДМС-пациентов). И это означает, что врач не может убрать какой-то пункт лечения или добавить его по своему усмотрению без описания причин. К этому мы ещё вернёмся подробнее на следующем шаге.

Есть план лечения


На основании планов лечения формируются приёмы и чеки к ним.

image

Услуги, добавленные в приём, можно удалить. Можно добавить сопутствующие услуги, которые будут предлагаться к приёму (анестезия, обработка и т. п.). Списки согласуются на этапе внедрения.

image

Стоимость приёма корректируется автоматически. Можно отметить тип прайса: ДМС, категория врача или дополнительные консультации специалистов.

image

image

План лечения можно распечатать как с ценами, так и без них:

image

image

При согласованном с пациентом плане лечения у него появляется соответствующий индикатор:

image

Все созданные планы отражаются у менеджера и главврача.

image
Приёмы можно объединять

Утверждать внутри каждой услуги и все вместе:

image

После согласования приёмы можно использовать в расписании. Если отметить их в записи, администратору будет оповещение:

image

Потери на этом этапе


  • Некоторые врачи не могут или не хотят говорить про деньги. Примерно треть врачей стесняется этого процесса, ещё около трети просто объясняет менее эффективно, чем администратор. Проблема в том, что без такого подробного плана лечения администратор просто не будет знать, что и зачем делают пациенту. С планом сможет провести диалог. В ходе этого диалога администратор объясняет пациенту все особенности плана. В итоге получается так, что врач только лечит, а администратор продаёт.
  • Очень часто в России при ситуации, когда пациенту нужно дорогое лечение, врачи стараются срезать углы и убрать пару пунктов из плана лечения, чтобы цена получилась более приемлемой. Надо сказать, что в плане лечения необязательных пунктов нет. Как правило, если убрать необязательную процедуру, то поменяются риски осложнений. То есть тот же коффердам для пациента сам по себе не нужен, но в десятки раз уменьшает риски. Стоит ли 5 % шанса воспаления нескольких десятков тысяч рублей? Пациент не вправе решать такие вещи. В США стоматология более сильно регулируется, и там есть допустимый уровень риска: за такую процедуру без коффердама просто отберут лицензию у врача. У нас можно убрать пункт. Так вот, система не даст это сделать без достаточного обоснования, например, какой-то уникальной формой зуба или индивидуальной непереносимостью.
  • Каждая операция имеет свой срок, то есть при высокой загрузке клиники врач не имеет свободных слотов. Конец приёма фиксируется. Это означает, что врач не может выполнить какую-то процедуру поверх плана и положить разницу себе в карман, и не может убрать что-то из плана лечения, чтобы сделать это отдельно вне фиксации в системе. Часто это выглядит так: врач считает, что пациент не согласится на высокую цену и отвалится, и убирает в плане лечения какой-то пункт. По факту он его сделает, потому что своя задница дороже. Но пациенту в счёт не поставит, а расходники спишет, если распоряжался ими аккуратно в этом месяце. Вроде бы сердобольный врач по-человечески прав, но это воровство и уменьшение доли расходников на следующих пациентов. Поэтому прощать такое категорически нельзя.

Самый странный случай был после пациентки, которая сделала очень кастомизированных процедур примерно на 5 миллионов рублей. Она специально приехала к нам из Австрии, а мы оптимизировали её пребывание в клинике так, чтобы сделать за минимум приёмов всё нужное. Так вот, она в конце последнего приёма сунула прямо в карман врачу около 90 тысяч рублей чаевых. Врач сразу сообщил владельцу клиники и спросил, что делать с деньгами. Естественно, оставить. А вот если бы он оставил деньги себе молча, и потом бы кто-то узнал, могли бы возникнуть подозрения в воровстве. Потому что наши люди таких чаевых не оставляют.

Закрытие приёма


Сканируем бегунок:

image

Открывается окно завершения приёма:

image

На этом этапе проставляем диагноз и результаты приёма, а также код Заботливый доктор, который напомнит, когда надо позвонить пациенту и что ему надо сказать, чтобы облегчить работу кол-центра:

image

image

Приём завершён:

image

Создана задача для кол-центра:

image

Приём можно закрыть и отправить пациента на оплату, заполнив карту потом. Можно заполнить карту при пациенте.

image

Карты зависят от врачей.

Вот ортодонты:

image

image

image

Карта ортодонта заполняется около пяти-десяти минут.

Карты всех врачей кроме ортодонтов заполняются за две минуты с помощью тегов и голосового набора:

image

Теги есть общие боль от кислого и выпадающими списками: зуб ранее лечили/лечили кариес/не лечили:

image
Отмечаем жалобы в тегах

После этого переводим в текстовый формат и быстро дорабатываем карту с помощью голосового набора и режима редактирования.

image

image

Кнопки верификации есть у главврача и других, ответственных за проверку карт, лиц.

image

image

Потери на этом этапе


  • Если возникают незадокументированные процедуры это шанс воровства. Процедура изменения карточки должна быть очень быстрой и приятной. Вся CRM это помощь врачу, а не препятствие. Увы, многие этого не понимают и строят ужасные интерфейсы. Те же творения 1С, которые мы пробовали использовать ещё в клинике, сильно мешают приёму.
  • Врачи уводят пациентов! Как это ни странно, но в России очень много врачей-совместителей, и они вполне могут предложить пациенту приём где-то в другой клинике подешевле. Если же мы всё сделали правильно от диагностики до плана лечения, то это очень легко вскрывается, потому что сравнение план-факт сразу показывает, что произошло. Да и звонит пациент администратору с вопросами, а не врачу. В итоге количество таких случаев сходит почти в ноль.
  • Пациенты уходят с планом лечения в другие клиники. Как смета одного подрядчика по строительству тут же показывается другому, так и пациент может взять свой план лечения за основу и понести его в другую клинику. Да, это случается. Но ничего страшного обычно в этом нет по многим причинам. Само наличие плана лечения никак не влияет на такое действие. Но то, что у вас он есть, а у других его нет, или он запутанный-непонятный, в конце концов играет в плюс.

Пациент ушёл на кассу


image

Значок рубля в расписании означает, что приём создан, но не оплачен. Когда пациент приходит на кассу, мы сканируем его карту:

image

Видим, что квитанция не оплачена:

image

Открываем кассу, нажимаем оплатить:

image

Можем как всю сумму списать с карты, так и часть списать с карты, часть взять наличкой и т. п.:

image

Ещё раз сканируем бегунок.

image

И завершаем визит:

image

Бегунок отвязывается автоматически.

Потом видим отчёты:

image

Тут, к примеру, красным выделены документы. Это значит, что не все документы из обязательного пакета распечатаны и подписаны с пациентом.

Дальше можно записать пациента на следующий приём. Открываем запланированные:

image

image

Просто перетаскиваем приём из колонки Незапланированные в Готовые к расписанию:

image

image

image

image

Готово! Приём записан в расписании.

image

В расписании администратор увидит приёмы по врачам, креслам, пациенту:

image

Так же по каждому врачу созданы задачи для администратора: позвонить и уточнить по состоянию пациента. Даты система рассчитает сама и напомнит всем участникам.

image

Обработка звонка:

image

Если до пациента не дозвонились или он просил перезвонить, отмечаем нужный пункт:

image

image

Потери на этом этапе


  • Пациента нельзя подвешивать у него всегда должен быть запланирован следующий приём. Если всё окончено гигиена через полгода или профилактический визит через N лет. Если нет следующий из запланированных приёмов.
  • Пациента нельзя терять. Обычно бывает так: составляется список на следующий обзвон. Если пациенту не дозвонились, то он не ставится в обзвон на следующий день, а просто пропадает. В итоге какой-то район ходит со здоровыми зубами (где клиника дозванивается по профилактике), а какой-то с более гнилыми.
  • Вовремя закрытый приём означает фиксацию времени: это нужно потом для работы системы антивор. Она действует примерно как эвристический анализатор антивируса и проверяет, не было ли у этого пациента нехарактерных отклонений по времени процедур, нет ли по врачу перекоса в сторону изменений в плане лечения от стандарта относительно остальных врачей клиники и стандарта вообще, нет ли ещё каких-то аномалий. Всё это собирается в статистику и показывается главврачу и владельцу.
  • Бывают потери на скидках: если врач или ассистент опоздали к началу рабочего дня, а пациент пришёл вовремя, то ему будут делать скидку. Нужно учитывать время прихода каждого.

Система антивор работает вместе с ассистентом и не мешает приёму и вообще процессу. Антивор отвечает за то, чтобы не было левых приёмов. Ассистент помогает быстро всё делать и убирает человеческий фактор. В итоге сверяется, чтобы план и факт совпадали, или все изменения были чётко обоснованы.

Это не все потери


Это далеко не все потери, и далеко не все процессы клиники. Но, надеюсь, примерное представление передать получилось. В целом могу сказать, что если клиника на ТТК в Москве имеет 800 тысяч рублей выручки в месяц это очень странно. Нормальный показатель около 1,5 миллиона в расчёте на кресло. Если у вас так пора или уменьшать потери, или же думать о том, что кто-то уже купил на этой разнице себе машину.

P.S. Подробнее можно посмотреть у нас на сайте вот тут.
Подробнее..

Перевод Пошаговый план для директора по качеству клиентского обслуживания, чтобы его не уволили в этом году

17.09.2020 14:13:09 | Автор: admin

Ваш новый начальник узнал о том, что улучшение качества обслуживания клиентов может обеспечить многомиллиардный дополнительный доход. Поэтому HR-менеджер разместил вакансию в LinkedIn ивы получили новую работу. По статистике, каждый четвертый работник в сфере CX (управление качеством клиентского обслуживания) потеряет свою работу в этом году. Если он неспособен доказать свою эффективность, его лишат зарплаты. Ваши цели кажутся недостижимыми? Без паники! Следуя изложенному ниже 90-дневному плану вы сможете уладить все проблемы и добиться определенных результатов.

Почему многих CX-специалистов ожидает провал

Работники, отвечающие за качество клиентского опыта (CX), не обеспечивают требуемую эффективность по двум причинам:

  1. Они делают ставку на крупные инициативы в области CX, на реализацию которых требуются месяцы, вместо того чтобы работать над постоянным улучшением CX. Такой подход лишает компанию дополнительной прибыли, от которой почти напрямую зависит возможность реализации этих крупных инициатив в области CX.

  2. Они не оценивают коммерческую составляющую проделанной работы. Беря во внимание только ИПЛ (индекс потребительской лояльности), вы оказываете CX медвежью услугу. Для реального успеха необходимо установить четкую взаимосвязь между внесенными изменения и доходом, снижением оттока клиентов, эксплуатационных затрат и прочим.

На чем сосредоточиться в свои первые 90 дней на новом рабочем месте

Чтобы добиться высокого качества обслуживания, которое удовлетворит даже самых требовательных клиентов и других заинтересованных сторон, придется приложить немало усилий, даже работая в компаниях, использующих долгосрочное планирование. Перед вами стоят 4 важные цели:

  1. Заручиться поддержкой со стороны всех работников компании. Все, от генерального директора до складского работника должны понимать важность стратегии ориентации на клиента. Каждое решение должно приниматься с учетом желаний и потребностей клиентов.

  2. Сформировать команду многопрофильных специалистов. Постарайтесь получить доступ к специалистам, чьи навыки включают умение проводить научные исследования, сбор статистики и анализ данных, написание текстового контента и программного кода, имеющих понимание психологии потребителя и навыки управления изменениями, а также разработки дизайна.

  3. Внедрить процесс, способствующий постоянной оптимизации полученного опыта в любом масштабе. Это должны быть организованные циклы исследований, экспериментов и обучающих процессов, которые приносят коммерческий результат.

  4. Сбор достоверных данных и анализ поведения клиентов для принятия решений. Вместо того, чтобы использовать данные ретроспективно для поддержки уже принятых решений, многие применяют их для принятия неких обоснованных решений.

Итак, чтобы достичь успеха, начнем с того, на чем вам нужно сфокусироваться на протяжении первых 30 дней работы.

Первые месяц: исследовательская работа

Вам нужно выполнить следующее:

  • Полностью пересмотреть весь цикл взаимодействия с клиентом.

  • Познакомиться с сотрудниками из различных отделов компании.

  • Запустить первое исследование.

  • Начать проводить эксперименты.

Вам нужно достичь следующих целей:

  • Начать составлять карты покупки, выявлять проблемные места.

  • Выяснить, кто из сотрудников за CX, а кого потребуется убедить в эффективности этого направления.

  • Убедиться в надежности имеющихся данных и результатов последних исследований.

  • Проанализировать результаты экспериментов, чтобы поделиться ими с представителями компании.

Свежий взгляд

На данный момент вы ничем не отличаетесь от ваших клиентов. Вы относитесь беспристрастно к работе, проделанной командой дизайнеров, и не считаете запутанный процесс оплаты покупки экономически обоснованным. Прежде чем узнать больше о проделанной работе другими специалистами, проверьте пользовательский опыт от начала до конца.

Постарайтесь узнать предысторию клиента. Например, вы являетесь сотрудником компании, продающей спортивную одежду. Предыстория может заключаться в том, что клиент начал заниматься йогой, и ему требуются специальные штаны для йоги. Начните с изучения вариантов, предлагаемых поисковыми системами (например, Google) и следуйте им. Перейдя на сайт вашей компании, ознакомьтесь с возможностями (инструменты поиска, фильтры, пользовательские отзывы, способ добавления товара в избранные и прочее), которые помогают найти нужный товар.

Просмотрите ссылки на соцсети, оформите подписку на новостную рассылку, протестируйте весь процесс оформления заказа для совершения покупки. На каждом этапе записывайте свои мысли, чувства и опасения, а также любые вопросы, которые возникают у вас как у клиента, и остались без ответа. Запишите информацию о том, что происходит после покупки: какие уведомления вы получаете об упаковке и доставке продукта, что произойдет, если купленный продукт (штаны для йоги) не подошел? Внимательно изучите процесс обратной связи.

Следуя этой пошаговой инструкции, автор этой статьи однажды выявил серьезную проблему на пути к покупке продукта, о которой не догадывался ни один сотрудник компании, состоявшей из более чем 200 работников. Речь идет о филиале компании, предлагающей услуги по покупке автомобилей. После оформления покупки был замечен e-mail, указанный мелкими буквами внизу квитанции. После отправки письма по указанному адресу ответ не последовал. Как оказалось, не было сотрудника, ответственного за обработку таких писем. На этот почтовый адрес приходили тысячи писем от клиентов, которые оставались не отвеченными. Это открытие было в дальнейшем расследовано Управлением честной торговли. Все клиенты, которые не получили ответ на свое письмо, направили жалобы в различные органы.

Если бы автор статьи не прошел этот путь с начала до конца, действуя как обычный покупатель, ошибка осталась бы незамеченной. Если бы кто-либо из сотрудников компании сделал это ранее, им бы удалось избежать проблем с клиентами и расследования.

Не спешите делать выводы, даже если вы не обнаружили какие-либо проблемы. Также, вы не извлечете пользы, если начнете критиковать плоды работы специалистов в области электронной коммерции в первую неделю своей работы. Дождитесь более убедительных результатов дополнительных исследований.

Омрачающие результаты

Наступил момент, когда вам нужно встретиться с заинтересованными сторонами: не с каждым человеком, но хотя бы с несколькими из каждой команды. На этом этапе вам нужно пообщаться с исполнителями конкретных задач, а не руководителями. Во время проведения этих встреч желательно чтобы сотрудники находились на своих рабочих местах. Таким образом вы сможете лучше понять корпоративную культуру компании. Насколько детально рассматриваются новые идеи? Является ли мнение самого высокооплачиваемого сотрудника наиболее весомым? Основаны ли принимаемые решения на конкретных данных? Насколько важны отзывы?

Узнайте мнения сотрудников о том, какие места требуют улучшений. Задумайтесь над полученными ответами, отслеживая проблемные моменты, чтобы выяснить причины их появления.

Например, если специалисты в сфере розничной торговли заявили, что потребители разочарованы недоступностью определенных товаров в определенных точках сбыта, постарайтесь выяснить, что является причиной этому. Разобравшись в проблеме, вы можете выяснить, что причиной всему является неправильно составленная рекламная кампания.

В разговоре со специалистами по закупкам может выясниться, что они не располагают данными о запасах в реальном времени, поэтому они даже не догадывались о существующем дефиците. Теперь вы понимаете как суть самой проблемы, так и причины ее появления.

Попросите сотрудников рассказать вам о их повседневных задачах. Они могут отличаться в зависимости от направления деятельности компании и используемых способов организации труда. Но, мы выделили несколько общих вопросов, которые стоит задать сотрудникам того или иного отдела.

Отдел продаж

  • Какие лиды поступают в отдел продаж?

  • Как выполняется процесс исходящих продаж?

  • Какие критерии используются для оценки потенциальных клиентов?

  • Какова дальнейшая судьба неквалифицированных лидов?

  • Можно ли принять участие в демонстрационных звонках, презентациях, исследованиях? Создайте список общих вопросов и возражений. Какое впечатление о компании производит отдел продаж?

  • Каково содержимое писем из переписок с потенциальными клиентами? Есть ли четкая последовательность действий? Насколько часто сотрудники общаются с лидами?

  • Как используются доступные инструменты продаж?

  • Какова дальнейшая судьба утраченных и выигранных лидов?

  • Как привлекают новых клиентов? Как их передают специалистам других отделов компании?

Отдел управления персоналом (HR)

  • Как составлены объявления о найме сотрудников? Как в них указаны цели и задачи компании?

  • Каковы критерии проверки, подходит ли кандидат на определенную должность? Проходит ли он проверку на наличие каких-либо мягких или жестких навыков, связанных с ориентированностью на клиента?

  • Можно ли поприсутствовать на собеседовании? Какие вопросы задают кандидатам? Какое общее впечатление о компании создает ее отдел управления персоналом?

  • Как ведут себя кандидаты в процессе собеседования (время ответа на вопрос, частота ответов)? Отвечают ли они на все поставленные вопросы или игнорируют их? Отправляются ли ответы с e-mail конкретного человека?

  • Можно ли пройти через все этапы собеседования? Какие задачи должны выполнить кандидаты?

  • Оставляют ли потенциальные кандидаты свои отзывы? Их можно проверить на сервисах, таких как Glassdoor.

  • Можно ли пройти процедуру адаптации с новыми сотрудниками?

  • Сбор каких отзывов о степени удовлетворенности персонала компании проводится? В каких областях компания показывает себя с лучшей стороны, а в каких имеются проблемы?

  • Можно ли ознакомиться с документами, касающимися политики компании?

  • Как специалисты отдела используют доступные им инструменты (существуют ли программы поощрения, образовательные и обучающие системы)?

Отдел маркетинга

  • Каковы общая маркетинговая стратеги и план?

  • Какие кампании и инициативы используются на различных этапах жизненного цикла клиента (например, адаптивные электронные письма, программа лояльности и прочее)?

  • Каковы основные маркетинговые посылы касательно ценности бренда и визуальной идентичности? Каковы ожидания клиентов?

  • Каков критерии оценки эффективности? Какие решения принимаются касательно будущих кампаний?

  • Какие решения и компании продемонстрировали наибольшую эффективность?

  • Какие кампании и решения оказались неэффективными?

  • Какие инструменты используются и сбор каких данных о клиентах проводится?

  • Каковы принципы сегментации клиентов используются?

  • Каковой является средняя карта путешествия клиента?

Производственный отдел

  • Каковы принципы сегментации клиентов используются?

  • Используются ли принципы персонализации продукта или услуги?

  • Можно ли присутствовать в процессе демонстрации продуктов и идей?

  • Каковой является дорожная карта продукта?

  • Как определяются и устанавливаются приоритеты, тестируются и оцениваются новые идеи и функции?

  • Какие данные об использовании продуктов и выявленных проблемах сохраняются?

  • Каковы методы разработки используются (водопад, гибкая разработка и прочие).

Отдел по работе с клиентами

Потратьте день на общение с водителями службы доставки и персоналом розничной торговли, а также работниками службы поддержки и персоналом, взаимодействующим с клиентами через социальные сети.

  • Как принимают клиентов? Каким является качество обслуживания? Какие впечатления складываются об общей карте путешествия клиента?

  • Какова проблематика клиентов?

  • Какие обходные пути для выполнения работы имеются в наличии? Например, клиент желает вернуть товар в точке розничных продаж, который был приобретен онлайн. Но система обработки розничных продаж не распознает онлайн заказы. Обходной путь принятие возврата вручную. Используют ли работники те 10 минут, которые они имеют в наличии при прямом взаимодействии с клиентом, чтобы задать ему определенные вопросы, касающиеся продукта?

  • Какие процессы вызывают определенные сложности? Что требуется для улучшения качества услуг?

  • Какие инструменты есть в наличии и сбор каких данных производится?

  • Каковыми являются основные жалобы и восторженные отзывы от клиентов?

  • Какими инструментами, упрощающими выполнение поставленных задач, располагают сотрудники (например, сценарии обслуживания клиентов)?

Отдел управления финансами

  • Какие способы оплаты доступны для клиентов?

  • Как проводится процедура возврата? Сколько времени это занимает? Взаимодействуют ли сотрудники отдела с клиентами напрямую?

  • Какие проблемы оплаты стоимости заказов существуют?

  • Какие продукты или услуги приносят наибольшую прибыль?

Инженерный отдел

  • Что представляет собой дорожная карта разработки продукта (инициативы по работе с клиентами, производство)?

  • Каковыми являются методы разработки продукта? (например, водопад, гибкая разработка)?

  • Как разрабатываются новые идеи и проекты? Как определяются приоритеты, проводятся тестирования и оценки?

  • Каковым является набор используемых инструментов? Какими возможностями они обладают? Есть ли у них какие-либо ограничения?

  • Какими данными о клиентах располагают сотрудники отдела?

  • Являются ли эти данные достоверными и подтвержденными?

В этот процесс вероятнее всего будут вовлечены несколько человек, имеющих обширный перечень идей. Но не все эти идеи следует воплощать в жизнь, по крайней мере сразу. Отнеситесь к своим клиентам с сочувствием, но пока не обещайте каких-либо решений или исправлений. Для правильной расстановки приоритетов требуются пользовательские отзывы.

Автор этой статьи сам допускал подобные ошибки. Услышав о проблемах отдела управления финансами, он предложил автоматизировать ручной учет. В итоге это оказался масштабный IT-проект, реализация которого практически не повлияла на качество предоставляемых услуг (CX). Ему не следовало принимать участие в работе над этим проектом, но он получал электронные письма с просьбой сообщить о достигнутых результатах каждый понедельник. Сложно отказать, когда в силу своего характера вы всегда стремитесь помочь людям. Но, вам нужно расставить правильные приоритеты в своей работе, а не пытаться исправить проблемы тех, кто о них заявляет громче остальных.

Встреча с представителями управляющего звена

Пришло время встретиться с руководителями отделов чтобы получить ответы на вопросы, касающиеся стратегии дальнейшего развития. Пригласите их на кофе или запланируйте более серьезную встречу, чтобы узнать ответы на вопросы, указанные ниже.

Персонал и способности

  • Какими навыками обладают члены вашей команды? Каких им не хватает?

  • Предусмотрены ли обучающие программы в области CX?

Выявите союзников по CX, а также недоброжелателей, которых придется переубедить. Создайте график зависимости интересов и власти чтобы упростить свою задачу.

Данные и инструменты

  • Какими наборами инструментов располагают работники каждого отдела? Что требуется для повышения эффективности их работы?

  • Какими данными они располагают чтобы иметь представление о клиентах и их опыте взаимодействия с бизнесом?

  • Есть ли разделение данных по отделам и инструментам? Каковы способы получения доступа к данным? Требуются ли навыки формирования SQL-запросов для получения информации или предусмотрен упрощенный интерфейс?

  • Есть ли какие-либо пробелы в дорожной карте, данные по которым отсутствуют?

  • Являются ли данные достоверными?

  • Производится ли запись результатов исследований клиентов, качественных пользовательских отзывов?

Стратегия и корпоративная культура

  • Каковы стратегия и план каждого отдела?

  • Какие ключевые показатели эффективности используются для оценки работы каждого отдела? Какие виды поощрения используются?

  • Каковыми являются общее видение компании и ожидания касательно пользовательского опыта? Каковы критерии оценки вашей работы?

Процессы и методология

  • Каковы методы оптимизации качества обслуживания клиентов используются?

  • Используются ли эксперименты для управления рисками имплементации новых идей? Существует ли количественная оценка роста цифровизации на пути к совершению покупки?

  • Какие процессы для разработки гипотез на основе данных и результатов исследований существуют?

  • Какие отделы занимаются расстановкой приоритетов в работе?

  • Какие идеи и информацию, получаемую от клиентов, используют для развития бизнеса в целом?

Выполнив все это, запишите сделанные выводы и определите пробелы между двумя точками: в которой бизнес находится на данный момент и в которой он должен находиться.

  • Стремитесь достигать поставленных целей;

  • Заручитесь поддержкой всей компании;

  • Создайте многопрофильную команду;

  • Внедрить процесс, способствующий постоянной оптимизации полученного опыта в масштабе;

  • Принимайте решения на основе достоверных данных и регулярно проводимых исследованиях.

Таким образом, вы создадите отличный тестовый документ, который будет демонстрировать все улучшения, достигнутые с момента вашего вступления в должность CX-директора.

Проведите свой первый исследовательский спринт

Это называется спринтом потому, что такие исследования нужно проводить постоянно, а не раз в квартал. Первоначальные исследования уже должны дать определенное представление о данных, которыми вы располагаете для бизнеса. Вначале настройте точки сбора данных. Подумайте о том, что требуется для завершения анализа пути к покупке и создания портрета клиента.

Убедитесь в том, что вы обладаете достоверными данными

Прежде, чем выявлять расхождения, убедитесь в том, что вы сравниваете данные одного типа. Например, что Google Analytics считает продажей? Соответствует ли это бэкэнд/бухгалтерской/CRM-продаже?

Кроме того, убедитесь, что вы сравниваете одни и те же таймфреймы. Чтобы избежать данных с другими настройками, достаточно проанализировать информацию по продажам, полученную за прошедший месяц. Этого периода достаточно для изучения данных, отправляемых вручную. Однако, их следует проверить с учетом внутренних бизнес-процессов.

Если достоверность данных не вызывает сомнений, можно приступить к их анализу, чтобы наметить счастливый путь к осуществлению покупки, выделив все основные точки соприкосновения, с которыми взаимодействуют клиенты, а также все проблемные места.

Планирование исследовательского спринта

Спланируйте пару целенаправленных исследовательских спринтов с учетом выявленных проблемных областей. Например, исследование процесса оформления покупки позволит отследить и получить аналитические данные, тепловые карты и результаты опросов пользователей, - то есть те данные, на основе которых можно получить представление о том, почему клиенты уходят в определенный момент.

Не ограничивайтесь данными, полученными от довольных пользователей. Осведомленные, но еще не купившие, а также отказавшиеся от покупки клиенты могут предоставить массу полезной информации.

Используйте методы исследования с учетом того, что вам нужно узнать. Например, можно использовать быстрые партизанские методы исследования (опрос покупателей в магазине) или предпочесть более структурированный подход:

  • Копировальное тестирование;

  • Исследование юзабилити;

  • Отслеживание движения курсора мыши и анализ тепловой карты;

  • Сортирование карточек и тестирование дерева сайта;

  • Обзоры;

  • Интервью;

  • Моделируемые исследовательские сессии;

  • Исследования на основе данных социальных сетей.

Проведение экспериментов

Запускайте эксперименты в первый месяц своей работы. Если вы внедрили новый инструмент тестирования, в первую очередь следует провести А/А-тест, чтобы убедиться в его работоспособности. Располагая рабочим инструментом A/B-тестирования, вы можете провести это тестирование. Получать первые результаты на раннем этапе работы это хорошее достижение. Однако, этот первый тест предназначен для запуска всех инструментов, а также выявления и устранения любых недостатков в инициированном вами процессе, который может отличаться от используемого ранее.

Выберите какой-либо простой объект для тестирования. Тест будет простым, если:

  1. Он проводится над чем-то, что не требует таргетинга и сегментации аудитории;

  2. Для его проведения не требуется вовлечение разработчиков и дизайнеров, так как его можно выполнить с помощью инструментов A/B-тестирования.

Хорошим вариантом может быть копировальное тестирования ценностного предложения.

Второй месяц: планирование

Вам нужно выполнить следующее:

  • Создать стратегию CX;

  • Разработать архетипы пользователей;

  • Отсортировать идеи с учетом приоритета для проведения тестирования;

  • Запустить сеансы поиска идей;

  • Продолжать проводить эксперименты;

  • Провести исследовательский спринт;

  • Сформировать дорожную карту CX.

Вы должны достичь следующих целей:

  • Выявить навыки, которыми должны обладать ваши сотрудники;

  • Внедрить работоспособные практики для CX и проведения экспериментов;

  • Рассказать о своих планах и поставленных целях всем представителям компании;

  • Поделиться результатами исследований и экспериментов с представителями компании.

Создание стратегии CX

В первые дни работы вам не следует сидеть сложа руки, придумывая идеи о том, что может сработать или занимаясь разработкой объемных документов, излагающих долгосрочные инициативы в области CX.

Вам нужно определить, какие сотрудники вам нужны, а также какие изменения в команде (например, кросс-функциональная команда) и рабочих практиках (например, водопад или гибкая разработка) требуются. Кроме того, вы должны продумать, каким образом вы будете повышать внимание к CX и обучать сотрудников.

Стратегия CX остается неизменной, так как она прошла проверку временем. Вам предстоит провести исследование, затем создать гипотезу, проверить идеи на работоспособность, поделиться полученными знаниями. На данный момент вы не можете заявить о каких-либо конкретных изменениях, так как вы не проверили все это в процессе тестирования.

Допустим, клиентам не нравится то, что доставка занимает много времени. На первый взгляд кажется, что это можно будет легко исправить, и вы добавляете решение этой проблемы в свою стратегию. Спустя три месяца наступит момент, когда вы вместе со своей командой начнете работу над новой системой, позволяющей сократить время доставки с 7 дней до одного.

Скорее всего, на планирование, определение объема работ, формирование запросов для новых поставщиков, интеграцию и тестирование новых программных продуктов потребуется несколько месяцев. В конечном итоге, может пройти полгода или год, прежде чем вы сможете предложить своим клиентам ускоренный вариант доставки.

Спустя это время вы обнаружите, что ускоренная доставка никоим образом не повлияла на коэффициент конверсии. Это может произойти потому, что клиенты не желают платить дополнительные деньги за ускоренную доставку и будут выбирать старый вариант 7-дневной доставки. Таким образом, вы допустили ошибку, выбрав стратегию без проверки идеи.

В данном случае следовало провести эксперимент, используя инструменты A/B-тестирования, чтобы выяснить, заинтересует ли доставка в тот же день потенциальных клиентов. Заказы можно выполнить даже вручную, лишь бы подтвердить идею до конверсии. Это позволит определить влияние на клиентов и сам бизнес всего за несколько недель с минимальными финансовыми затратами.

Если результаты теста показали эффективность быстрой доставки, ее добавят в дорожную карту. Такой подход даже может способствовать более быстрой реализации новой услуги, так как бизнес заинтересован увеличить свою прибыль как можно скорее.

Никогда не давайте свое согласие на реализацию крупных и дорогостоящих CX-проектов до того момента, пока вы не получите доказательств их работоспособности.

Расстановка приоритетов идей перед тестированием

На данный момент вы должны располагать перечнем идей, разработанных в первый месяц работы. Теперь нужно расставить приоритеты в этом перечне. Существует несколько методов расстановки приоритетов: PIE-структура, ICE-оценка и прочие. Однако лучшим вариантом является триангуляция результатов исследований определения ценности гипотез и оценки требуемых усилий для их реализации. Что касается методов, которые пытаются предсказать влияние теста на способ определения ценности идей, они дают точные результаты далеко не всегда. Лучше всего работать с трафиком на странице, чтобы оценка была более объективной. С этой целью можно использовать PXL-шаблон.

Некоторые идеи будут взяты из результатов JDI-тестирования, которые являются проблемами, нуждающимися в простом исправлении (например, неработающий элемент в форме заказа). Их можно добавить в дорожную карту, чтобы разработчики устранили эти проблемы, пока вы запустите несколько своих первых тестов.

Сеансы поиска идей

Вовлеките специалистов вашей команды в сеансы поиска идей (не только UX-дизайнеров, а и аналитиков, и разработчиков). Это поспособствует лучшему пониманию клиента и разработке инновационных решений.

Сеанс поиска идей проходит по следующей схеме:

  1. Предоставьте гипотезу, обоснованную результатами исследования конкретной проблемы.

  2. Разместите на стене архетипы пользователей, основанные на имеющихся данных, а также пути клиентов к совершению покупки.

  3. Раздайте листы бумаги и карандаши каждому участнику, попросите их сделать наброски потенциальных вариантов решения проблемы, необходимых для проверки вашей гипотезы.

  4. Попросите каждого участника предоставить лучшую идею.

  5. Проведите повторный 10-минутный сеанс поиска идей.

  6. Соберите окончательные идеи для проверки во время тестирования. Данная гипотеза готова для помещения в дорожную карту CX и прохождения проверки.

Построение дорожной карты CX

Возьмите список гипотез, выстроенных с учетом приоритетов, и взаимодействуйте с коллегами, чтобы выяснить такие параметры, как требуемый размер выборки и время, необходимое для запуска каждого теста. Чтобы результаты были точными, необходимо продумать интервалы между тестами с целью предотвращения попадания пользователей в несколько тестов подряд.

Третий месяц: масштабирование

Вам нужно выполнить следующее:

  • Масштабировать исследования и эксперименты.

  • Согласовать цели и показатели с поведенческими факторами и результатами CX.

  • Сформировать образовательную программу корпоративного масштаба.

  • Создать отчет с результатами проделанной работы за 90 дней.

Вам нужно достичь следующих целей:

  • Увеличить скорость проведения исследований и экспериментов для принятий решений касательно более глобальных инициатив в области CX.

  • Развить навыки и улучшить знания чтобы сосредоточиться на CX компании.

  • Стимулировать ориентацию на CX в масштабах компании.

  • Получить результаты исследований и экспериментов, поделиться ими с представителями компании.

  • Заручиться поддержкой руководящего звена, поделившись результатами проделанной работы.

Масштабирование исследований и экспериментов

По мере имплементации процессов, вы сможете наращивать число проводимых экспериментов и исследовательских спринтов. Хотя ваш подход зависит от организации, вы можете внедрить эти методы в другие отделы и функциональные части компании.

На текущий момент вы уже должны располагать результатами нескольких тестов, которые могут подтвердить или опровергнуть эффективность более крупных инициатив в области CX. Если результаты неубедительные, вы сможете проверить различные гипотезы. Эти результаты могут служить вашим ориентиром для последующего заполнения дорожной карты.

Запуск образовательной программы

За два месяца работы у вас должно появиться четкое представление о корпоративной культуре и отношению к CX, а также используемых подходах к принятию решений на основе имеющихся данных. Приоритетность образования зависит от вашего текущего места работы. Если вы не заручились поддержкой, загружать себя дополнительной работой не имеет смысла. Образование и общение два важных инструмента для продвижения CX инициатив.

При разработке обучающей программы ее следует адаптировать с учетом уровней и навыков, необходимых для различных отделов компании. Например, финансовому директору вряд ли нужны знания SQL, но умение составлять ежемесячные презентации о том, как интерпретировать данные и оценивать рентабельность инвестиций, связанных с вашей деятельностью, - весьма полезный навык. Для создания карты навыков, необходимых работникам конкретных отделов, можно использовать обычный Excel-документ.

Заполните матрицу требуемых навыков для работников конкретного отдела, создавайте обучающий контент или берите его из внешних источников. Для оценки эффективности учебной программы можно использовать модель Филипса.

Стандартные электронные курсы CX оказывают незначительный эффект. Старайтесь мотивировать сотрудников к обучению. Брендинг учебной программы должен быть таким, чтобы вовлекал в нее новых участников. Например, директор отдела по работе с клиентами Дэн Моррис (компания Moo) черпал вдохновение в классике кино. Можно создать многоуровневую программу обучения и поощрять сотрудников за успешное прохождение каждого уровня.

Стимулировать к обучение это хорошо, но важнее всего стимулировать работников использовать полученные навыки в повседневной работе. Лучшим решением будет провести встречу с руководителями отделов и представителями отдела кадров, чтобы разработать показатели, измеряющие поведенческие особенности и результаты. Эти показатели должны быть прозрачными для всей компании. Можно использовать инструменты реализации методологии постановки амбициозных целей, такие как 7Geese.

Коммуникации

Смоделируйте поведение, которое вы бы хотели видеть если не в мире, то по крайней мере на рабочем месте. Принимая решения, всегда поясняйте данные, на которые они опираются. Если команда принимает решения, она должна действовать таким же способом.

Это поведение будут наблюдать работники других отделов. Это работает так же, как люди подхватывают крылатые фразы. Руководитель отдела роста и маркетинга компании Otter.ai Чанг Чен пояснил, как этот подход помогает другим сотрудникам использовать информацию о клиентах в рамках всей компании: мы записываем, расшифровываем и резюмируем все наши интервью с клиентами, делимся результатами с каждым сотрудником. Также мы делимся пользовательскими отзывами из социальных сетей и каналов специалистов поддержки. Теперь наши сотрудники мотивированы словами наших клиентов, так как они слышат их напрямую.

Отчет с результатами проделанной работы

Ваша последняя задача состоит в разработке документа для высшего руководства. Он должен содержать всего несколько слайдов. Продемонстрируйте, как используемый вами подход повлиял на прибыль и сформулируйте результат в контексте используемой стратегии CX (исследование, гипотеза, подтверждение идеи, полученные знания).

Смоделируйте процесс принятия решений, чтобы не показалось, будто ваши идеи оказались работоспособными лишь случайно. Вы использовали системный подход, основанный на данных, правильной расстановке приоритетов, а также статистически проверенных идеях, и в конечном результате это привело к успеху.

Заинтригуйте руководство, рассказав о том, что вы включите в дорожную карту в будущем, покажите другие крупные CX-проекты, которые были утверждены, вместе с предполагаемой прибылью от их реализации.

На последнем слайде нужно показать то, что вам необходимо, чтобы продолжать получать результаты (например, дополнительная поддержка со стороны руководящего звена, дополнительные ресурсы и т. д.)

Заключение

Эти три месяца будут очень напряженными. Но, приведенный план поможет вам продвинуться в четырех важнейших направлениях, что необходимо для достижения успеха в новой должности:

  1. Вовлеченность всех сотрудников компании;

  2. Многопрофильная команда;

  3. Постоянная оптимизация CX;

  4. Решения, основанные на данных, что в конечном итоге обуславливает прибыль.

Многие профессионалы в области CX сосредотачивают внимание на работе над крупными инициативами вместо того, чтобы улучшать CX. По этой причине им сложно связать результаты с проделанной работой.

Предложенный выше подход гарантирует то, что вы станете лучшим сотрудником месяца. Может, даже получите более высокую должность.

Подробнее..

Об устаревании кода и жизненном цикле ПО

17.09.2020 22:09:55 | Автор: admin


Стартап, новые технологии, современные языки и фреймворки. Всё это так волнительно, когда мы начинаем делать что-то с нуля. И обязательно стараемся выбрать современные, популярные, любимые миллионами технологии для нашего проекта. Но время не останавливает свой неумолимый бег, и вдруг мы оглядываемся назад и видим, что нашему стартапу уже 15 с лишних лет. И мир вокруг давно изменился. А у нас в проекте всё тот же Basic/Delphi/Fortran/whatever. И как с этим жить?



Нет, я вовсе не хочу разводить очередной холивар и это далеко не набрасывание на вентилятор. Просто это такая моя личная боль, вести проекты на миллион+ строк кода на устаревших технологиях, в частности на Delphi.

И становится интересно, а сколько же в среднем вообще живет успешный проект. Если посмотреть вокруг, то в принципе проектов с бородатой историей довольно много. Это и WinRAR, и Microsoft Office, и AutoCAD, и Photoshop, и 3DSmax и множество других. Причем это проекты для массовой аудитории. А сколько существует различных банковских систем, КИС, CRM и прочих корпоративных систем различного уровня. И многие из них писались далеко не в последнюю пятилетку.

Хотелось бы конечно идти в ногу со временем, но мигрировать крупный проект с одного языка на другой, на мой взгляд, тяжёлая задача. Мало того, что пока идет эта миграция и написание нового кода, старый проект должен тоже продолжать работать, жить и развиваться. В новом проекте надо повторить всю логику старого, а она не всегда четкая. В старом проекте много логики может быть построено на библиотеках, которые давно уже не поддерживаются своими разработчиками. В новом проекте этим библиотекам надо искать замену. Если это визуальные компоненты, то с этим еще сложнее, потому что помимо поиска замены нужно еще учитывать, как переписать код работы с этими визуальными компонентами, чтобы новый компонент повторял поведение старого. Конечно, всё решаемо и нет цели повторить работу проекта на 100%, но даже на 50% сделать это очень и очень сложно и в процессе такого переписывания может оказаться, что та платформа/язык, на которую решили переписывать, чем-то не подходит или уже теряет популярность.

Конечно, я в бОльшей степени говорю именно о крупных проектах, со значительным слоем логики. Миллион строк и больше. Т.е. не о мини-сайтах, не о микросервисах, а о таких себе монолитах (пусть даже они и побиты на компоненты/слои и т.п.).

Хотелось бы узнать мнение здесь присутствующих, сталкивались ли вы с подобными проблемами и как поступали в подобных ситуациях?

Какие решения вы бы посоветовали применить при разработке, чтобы через 10-15 лет не было желания перевести проект на другую платформу?

Спасибо за ответы!
Подробнее..

Discovery бэклог как не упустить важное

18.09.2020 12:15:01 | Автор: admin
Всем привет! Меня зовут Юля, я отвечаю за развитие продукта Social Trading в Exness. Немного обо мне. Работаю в продуктовой разработке восемь лет в роли продакта. Начинала заниматься этим, когда эта роль в российских компаниях так даже и не называлась. Сейчас мы вместе с командой делаем продукт, который позволяет трейдерам с небольшим опытом инвестировать на финансовом рынке. Если кратко, суть в том, что эти трейдеры копируют понравившиеся стратегии более опытных трейдеров.

Давайте на примере нашего сервиса поговорим о том, откуда брать идеи для бэклога и как сделать его полезным и удобным инструментом для работы.



Итак, какая важная часть работы продакта? Конечно, ведение продуктового discovery бэклога. В discovery бэклог мы фиксируем и систематизируем все идеи и гипотезы по достижению продуктовых целей. Этот же бэклог есть источник для формирования delivery бэклога, то есть списка идей, которые мы передаем в разработку. Если задача delivery бэклога сформулировать то, что несет максимальную ценность в данный момент, то задача discovery бэклога фиксировать все, что может быть полезно сейчас или в будущем.

Тема поиска идей для продуктовой разработки крайне актуальна. Мы часто обсуждаем ее с продактами, которые работают в других компаниях. Создается впечатление, что источники идей сильно зависят от культуры компании, устоявшихся процессов или личных предпочтений продактов. По факту чаще используют ограниченное число источников, а другие просто не задействованы. Бывает, продукт пилится просто в соответствии с утвержденной стратегией, и то, как воспринимают его клиенты, с какими проблемами сталкиваются каждый день никого не беспокоит. Или наоборот, продакты закапываются в цифры, днями и ночами подкручивают воронку и улучшают опыт клиентов, не внося по факту никаких значимых изменений в продукте и не запуская чего-то, что может дать реальный прорыв или конкурентное преимущество в будущем.

Также часто сталкиваюсь с тем, что продакты воспринимают определенные источники идей не как источники идей, а как раздражители и барьеры развития продукта. Особенно это касается сотрудничества с другими подразделениями компании: Вот, пришли сейлзы, опять чего-то хотят, диктуют, что нам делать. Что они вообще понимают, я продакт, я вижу цифры, я знаю свой продукт лучше всех.

Но задача discovery бэклога фиксировать все проблемы, идеи, гипотезы. И если используется только часть источников, то бэклог получается однобокий, а вслед за ним таким станет и продукт.

Теперь расскажу, какие источники используем мы. Итак, поехали.

image

Первый пункт плана послушать клиента


Пожалуй, самый очевидный источник, но это не уменьшает его ценность.

Клиенты непрерывно делятся фидбеком: оставляют отзывы в сторах, комментарии в соцсетях и на форумах, пишут сообщения в службу поддержки. Может, проще оставить их без внимания, это ведь работа саппорта разбираться с обращениями клиентов? Или все-таки лучше выжать максимум из ситуации и взглянуть на это как на массовый, бесплатный канал получения идей в режиме 24х7? В Exness мы постоянно читаем, что пишут клиенты в сторах и в письмах в службу поддержки (стоим в копии переписки), имеем чат с саппортом и сразу фиксируем все идеи.

На а как получить фидбек клиентов по конкретному вопросу? Здесь помогут исследования лично, по телефону или online; глубинное интервью, опрос, UX-тестирование. Все зависит от задачи и наличия времени. Исследование можно легко провести самому online: множество сервисов вам в помощь или же попросить саппорт, продажи. Последние с радостью примут предложение, ведь какой sales откажется от позитивного повода для контакта с клиентом?

Также у нас на постоянной основе запущено исследование NPS в приложении с полем для фидбека в свободной форме. Его обычно заполняют подробно те, кто ставит низкую оценку. Мы это понимаем, но в любом случае собираем там много полезной информации не только о том, чего именно хотят пользователи (многое из этого уже есть в бэклоге), но и о том, какому числу пользователей это актуально. Все это помогает при определении приоритетов.

Так, одним из самых популярных пожеланий инвесторов было добавление Stop Loss и Take Profit (автоматическое закрытие инвестиции при достижении определенной суммы). Мы запустили эту фичу в августе. Посмотрим, как отразится это на общем уровне NPS, и какое пожелание будет в топе в сентябре.
Там же запускаем быстрые опросы инвестиционный профиль, предпочтения по рынкам и так далее.

image

Что еще? Ежемесячно проводим глубинные интервью с разными сегментами клиентов: пользователями, которые ушли в отток, самыми высокодоходными клиентами, инвесторами, которые являются одновременно и трейдерами, пользователями, которые перешли на шаг платежа, но не сделали его и так далее.

Интервью проводим по фреймворку Job to be done, он позволяет получить максимум инсайтов юзера. Каждый раз узнаем массу нового, так как продукт развивается, а клиенты все разные, и они также развиваются вместе с нами.

Яркий пример. Узнали, что многие новые пользователи делают депозит и сразу вывод для того, чтобы протестировать, как вывод работает. И если работает хорошо, они доверяют брокеру, принимают решение о сотрудничестве. У нас вывод делается полностью автоматически, средства поступают быстро (время зависит только от правил пополнения выбранного клиентом платежного средства), клиенты это видят, ценят и начинают с нами работать.

Данные не умеют говорить, но задают вопросы


У продуктов обычно существуют целевые метрики, по которым измеряется его успех. Если метрик нет, то лучше сделать так, чтобы они появились. Метрики и цели по ним часто являются результатом каскадирования метрик компании, измерителями достижения цели продукта (например, в виде OKR, Objectives and Key Results) или же синтезом этих двух вещей. Например, число активных пользователей, время, проводимое в приложении одним пользователем за период, доход на одного пользователя, NPS.

Так или иначе, есть метрики, есть целевые значения, которые мы хотим достичь к определенному времени, есть их фактическое состояние на сегодня. И для того, чтобы из состояния факт перейти в состояние план, в продукте нужно что-то менять.

Чтобы понять, что менять, каждая метрика обычно раскладывается на метрики нижнего уровня (конверсия в регистрацию/ покупку/ оплату, повторные визиты, средний чек, отток), ведется трекинг каждой такой метрики, определяется то, какую из них нужно и можно улучшить, и формируются гипотезы по тому, какие фичи нужно сделать, чтобы этого достичь.

Сами по себе данные, конечно, не умеют говорить и никаких идей принести не могут. Они скорее поднимают вопросы, чем дают ответы. Но чем больше мы смотрим на цифры под разными углами, чем больше вопросов себе задаем, тем больше гипотез у нас появляется. Особенно если совместить этот пункт с другими.

Покажу на примере. Наша цель в 5 раз увеличить число активных пользователей (активный пользователь имеет открытую инвестицию на 7 день после регистрации и позднее). Мы смотрим на конверсию скачивания в первую инвестицию, сравниваем с аналогичным показателем в другом продукте Exness (мобильное приложение для самостоятельного трейдинга). Видим, что там конверсия в полтора раза выше, хотя по идее наш продукт более простой и направленный на массового потребителя. Начинаем смотреть глубже: для разных стран, разных типов трафика разница почти везде есть, особенно большая для рекламного трафика. Берем самую популярную страну и рекламный трафик, строим воронку по каждому шагу и видим, что самое большое отличие на шаге пополнения баланса. Встречаемся с коллегами, просим поделиться секретом успеха, и все оказывается просто. Все мы изначально внедрили стандартный процесс: клиент кликает в Сделать депозит, заполняет анкету о себе, прикрепляет документы, потом выбирает платежное средство. Коллеги сделали A/B тест, где просто поменяли местами эти шаги и сначала дали выбрать платежное средство. Пользователь на первом шаге видит, что есть удобный для него способ пополнения (клиентам это очень важно, так как в разных странах распространены совершенно разные способы). И дальше он уже готов потратить время на заполнение анкетных данных. А/В тест показал свой эффект, коллеги раскатали на всех. Уже через неделю мы запустили аналогичный тест у себя, который также показал статистически значимый прирост в конверсии.

Конкуренты формируют ожидания, или куда движется рынок


Если ваши клиенты уже пользовались продуктами конкурентов, то у них уже есть ожидания на основании этого опыта. Если у конкурентов есть фичи, которые клиенты считают ценными, их отсутствие в вашем продукте вызовет разочарование, клиенты не начнут или перестанут пользоваться продуктом. Речь не идет о слепом копировании того, что есть у других (не все имеющееся там несет ценность для клиентов). Важно понимать стандарт качества рынка и соответствовать ему. Он постоянно меняется, поэтому рука должна быть на пульсе.

Пока мы смотрим на воронки, конверсии, отзывы клиентов, мы очень погружаемся в детали и можем пропустить глобальный тренд. Чтение исследований и обзоров рынка позволяет ненадолго вытащить голову из песка и взглянуть на происходящее немного со стороны. А также добавить в бэклог что-то, что уже происходит, но не лежит на поверхности.

А что в это время делают ведущие digital-сервисы?


Ведущие локальные и мировые digital-сервисы также формируют привычный клиентам опыт и ожидания, даже если работают на другом рынке. Если клиент смог оплатить в Интернет-магазине одежды покупку через Apple Pay, он захочет оплатить также и бронирование отеля. Ну и не зря эти ведущие сервисы ведущие. У них можно черпать идеи по стандартным юзер-сценариям, таким как регистрация, онбординг, каталоги товаров/ услуг, платежные сервисы и так далее.

О чем могут рассказать коллеги


image

Коллеги также пользуются или могут пользоваться продуктом. Да, их вижен несколько искажен, а методички по маркетингу говорят никогда не тестить продукт на коллегах, но они также сталкиваются, как и клиенты, с проблемами в использовании, у них также есть ожидания от продукта. Это быстрый и доступный источник информации и идей.

В прошлом месяце мы вместе с коллегами, отвечающими за тренинги и качество, провели конкурс среди сотрудников. Сотрудники компании приняли участие в нем в качестве провайдеров торговых стратегий (130 человек выступили в этой роли) и в качестве инвесторов (250 человек выступили в этой роли). В течение двух недель одни трейдили, другие инвестировали в них. Сейчас мы подводим итоги, выявляем победителей и параллельно собираем фидбек. Мы получили десятки развернутых, подробных комментариев, и часть из них уже вошла в план четвертого квартала, часть будет сделана позднее.

Стратегия компании


У компании есть стратегия, она обычно формулируется как минимум на год и описывает то, где компания хочет оказаться к этому сроку. Это может быть выход на новые рынки, запуск новых направлений бизнеса, выход на новую клиентскую аудиторию и так далее. Продукт является частью бизнеса компании, а значит, должен поддерживать реализацию этой стратегии. Поэтому все, что нужно сделать в продукте для реализации стратегии тоже часть бэклога. Помимо общей стратегии, в компании могут возникать отдельные стратегические инициативы. Это нечто менее глобальное и более краткосрочное, но также нуждается в поддержке продуктом.

А что за продукт мы вообще строим


Мы тратим много времени на цифры, клиентов и конкурентов. Конечно, идеи, которые мы там находим, ценные и важные, но их нужно было реализовать вчера. И если мы хотим быть не как на рынке, а отличаться чем-то, нести уникальную ценность, если хотим вырасти в разы, то должны сделать что-то, чего еще никто не сделал, чего не просят клиенты, так как даже не догадываются, что так бывает. Описание этого содержит целевой вижен продукта. Каждый день появляются задачи по удержанию проваливающихся метрик, решению багов, доработок по пожеланиям клиентов, но вижен это путеводная звезда, по направлению к которой нужно упорно идти.

Сотрудничество внутри компании


Продукт чаще всего не существует отдельно и сам по себе. Есть другие подразделения в компании, которые оказывают влияние на продукт и/ или зависят от него: поддержка, маркетинг, продажи, антифрод, финансы. У этих подразделений есть свои цели и свои проекты, для реализации которых нужны доработки в продукте. Часто вижу, что такие задачи воспринимаются продакт менеджерами негативно: Вот снова пришли со своими идеями/ запросами. Да, это они авторы этих идей, но это не значит, что эти идеи бесполезные. Они могут принести в результате больше пользы продукту, чем ваши самые классные (потому что ваши) идеи.

В других подразделениях люди также изучают рынок, клиентов, конкурентов, но часто под несколько иным углом зрения, поэтому общение с ними, как с экспертами в их области, может дать очень много полезных знаний, идей и обогатить бэклог.

Продуктовой команде тоже есть, что добавить


Команда чаще всего источник идей по техническим улучшениям, и о том, что они важны, думаю, говорить не нужно. Но помимо этого у команды могут быть и продуктовые идеи, поэтому важно привлекать их к процессу генерации идей и бережно относиться к их фидбеку.

Подытожим


Вот такие источники мы используем в работе для ведения Discovery бэклога. Discovery бэклог это место, где нет плохих или хороших идей, нет ваших идей и идей чужих. Задача продакта быть радаром, который собирает идеи на всех уровнях (клиенты, компания, рынок). Пусть в бэклоге будет все, что имеет отношение к целям продукта. И если бэклог правильно структурирован, все задачи, проблемы, гипотезы четко описаны и систематизированы, то при формировании бэклога разработки, ничего не будет упущено, а шанс того, что в разработку попадет то, что несет наибольшую ценность выше.

Ну и небольшие заметки по тому, как фиксировать идеи наилучшим образом:

  • Ориентироваться в списке из 200 идей сложно, поэтому лучше сразу систематизировать их по темам, инициативам, каким-то крупным логическим кускам;
  • Если изначально идея была сформулирована как проблема, то лучше зафиксировать наиболее четко смысл проблемы и рядом вариант решения в виде гипотезы. Когда начинаешь заниматься этой проблемой, может оказаться, что есть лучшее решение;
  • Любая задача делается не просто так, а чтобы, как мы уже говорили выше, прокачать какую-то метрику или в рамках стратегических инициатив. Мы прямо в документе сделали соответствующий раздел, где перечислили их. Он позволяет при добавлении идеи или проблемы заматчить ее с целями. И те идеи, которые не матчатся, сохраняются, но отдельно.

Полный, систематизированный, регулярно обновляемый discovery бэклог это лучший помощник продакта при выборе того, какие задачи идут в разработку, а также для коммуникации планов внутри компании. Если тратить на него время регулярно, то процесс планирования будет занимать значительно меньше времени.

Сегодня я остановилась на источниках вдохновения, но понятно, что не менее интересна и тема приоритизации идей в бэклоге. Как решить, что реализовывать через год, а что включить в ближайший спринт? Ответ на этот вопрос очень сильно зависит от стадии жизненного цикла продукта, разрыва между план-фактом метрик, целей, которые стоят перед продуктом, ситуации на рынке, совершенства технической составляющей и многих других факторов.

Если эта тема вам интересна, откликается, то об этом можно будет поговорить в отдельной статье. Желаю всем найти свои источники и сделать продуктовую разработку максимально эффективной!
Подробнее..

Организация работы в креативной команде опыт Wrike, Miro, Revolut

18.09.2020 16:04:09 | Автор: admin


Мы в Wrike решили сделать встречу для сотрудников креативных команд дизайнеров, маркетологов, проджект-менеджеров чтобы поговорить об эффективных процессах там, где рутина может убить творчество. Позвали дизайн-лидов из Revolut, Miro и Wrike, чтобы они поделились своим опытом, наработками и секретами.
24 сентября, в 18:00 по Москве. Онлайн.


Спикеры:





Полгода мы работали над концепцией бренда в офисе, и через неделю после выхода на удаленку переосмыслили ее за неделю. Поговорим о методологиях быстрой генерации идей для распределенных команд, о планировании от формирования брифа до финального утверждения и о том, как сохранить бодрость духа, когда сроки горят.



В Miro мы делаем продукт для работы распределенных команд, и когда весь мир переключился на удаленную работу, мы столкнулись сразу с несколькими глобальными задачами:
Как трансформировать процессы в команде под удаленную работу
Как улучшить опыт + 4 миллионов новых пользователей
Какие ритуалы в дизайн-команде должны помогать обмениваться опытом и двигаться быстро

Я расскажу о том, как мы решали эти задачи и трансформировали дизайн-процесс после выхода на ремоут, как в компании сфокусировались на улучшении пользовательского опыта и внедрили 60+ улучшений за полтора месяца, а в конце поделюсь практиками организации удаленной работы дизайн-команды, которые помогут сохранять прозрачность и доносить ценность до пользователей.



Приходите и готовьте вопросы спикерам. Мы всегда рады диалогу в это непростое онлайн-время.

Регистрация

Подробнее..

Change Management 3 Колесо изменений и борьба с партизанами

24.09.2020 12:15:14 | Автор: admin

Привет, Хабр! Это мой заключительный пост на тему Change Management, в котором я хочу рассказать о модели Change Well и ее пользе для бизнеса. Мы рассмотрим, чем в партизан отличается от саботажника (в контексте внедрения изменений, конечно), как кувалда может помочь ускорить изменения в организации и чему мы можем научиться у создателей компьютерных игр.

Одним из подходов к управлению изменениями в организациях и не только является модель Колеса Изменений (Change Well) Розабет Мосс Кантер. По замыслу известной ученой из Гарвардского университета, для успешного внедрения изменений мы должны сконцентрироваться на активностях из 10 категорий. Как и среди спиц колеса, из них нельзя выделить более или менее важные. Но если одна или несколько спиц деформированы, далеко уехать будет непросто. То же можно применить и к внедрению изменений.

  1. Первая спица подчеркивает важность общего видения. О распространении единого взгляда на изменения мы уже говорили, обсуждая модель Коттера в прошлом посте. Здесь все принципы остаются такими же.

  1. Символизм отличный помощник при продвижении изменений. Один из ярких примеров символических действий продемонстрировал руководитель компании Haier, на данный момент одного из крупнейших мировых производителей бытовой техники. В 80-х Haier был небольшой компанией, которая выпускала холодильники. Одним из первых шагов ее руководителя Чжан Жуйминя был разворот к качеству. Но заявление так и осталось заявлением, пока директор не пришел с проверкой на завод. Когда ревизия выявила значительное количество брака, директор взял в руки кувалду и начал громить некачественные холодильники, а потом поручил сотрудникам делать то же самое. Работники были шокированы, ведь стоимость каждого холодильника составляла их двухлетнюю зарплату. Это был яркий символ отказа от прошлого и нового подхода к производству, в том числе благодаря которому компания изменилась и стала тем, чем она является сейчас. Кстати, кувалда до сих пор выставлена в музее в штаб-квартире компании Haier.

  1. Постоянное руководство и понятный процесс контроля необходимы при внедрении любых изменений. Для достижения успеха нужно оценивать риски, сравнивать цели, проверять отклонения от плана. Для всех должно быть понятно, как именно мы проверяем прогресс и успешность внедрения.

  2. Обучение необходимо сотрудникам, которые впервые сталкиваются с новой для себя деятельностью. Это могут быть как мастер-классы от приглашенных экспертов, так и внутренние специалисты или информационные ресурсы.

  3. Спонсоры это сотрудники компании с административным весом, которые будут поддерживать изменения на высоком уровне, а Чемпионы те сотрудники, которые раньше остальных начинают работать по-новому, вырабатывают новые подходы и методы. Именно они дают пример другим сотрудникам своим опытом и первыми победами.

  4. Быстрые победы, о которых можно сообщить сотрудникам, подогревают общее отношение к изменениям. Как мы уже отмечали раньше, будет полезно подготовить возможности для быстрых побед еще до начала процесса изменений.

  5. Обмен лучшими практиками и коммуникации способствуют распространению изменений внутри компании. Редко выходит, что все подразделения одинаково успешно внедряют новые практики, у кого-то это обычно выходит лучше, чем у других. Именно они и могут стать источниками лучших практик и проводниками изменений.

  6. Политики и процедуры могут быть как некими очевидными негласными правилами, так и закрепленными на уровне документов корпоративными законами. Именно поэтому стандарты нужно менять, причем делать это целенаправленно.

  7. Контрольные точки нужны для того, чтобы оценить, соответствует ли движение запланированным этапам, а обратная связь от спонсоров изменений помогает понять, насколько происходящее соответствует бизнес-целям компании.

  8. А в финале важно поощрить отличившихся тех, кто помог довести начатый процесс до успеха. Ведь наверняка это не последний процесс изменений в организации, а признание один из важных факторов мотивации.

Условно колесо можно разделить на культурный и процессно-инженерный сегменты, но это не отменяет важности каждой из спиц для достижения цели.

Еще одна интересная особенность этой модели заключается в том, что противоположные спицы связаны друг с другом.

Например:

  • Символы и сигналы не могут быть распространены без коммуникаций

  • Тренинги и инструменты позволяют убедиться, что люди смогут реализовать задуманное, а контроль убедиться, что действительно реализуют

  • Чемпионы должны быть награждены и получить общественное признание

Личный опыт

Еще до работы в Acronis мне довелось поучаствовать в проекте внедрения системы контроля безопасности выпускаемого продукта. Проект предполагал новый подход к ревью безопасности кода от участия команды Security в дизайне новых фич, до ручного пентеста и автоматизированного фаззинга непосредственно перед релизом. И внедрить это предстояло в организации с более чем 200 разработчиками, распределенными по миру.

С самого начала было очевидно, что вряд ли все разработчики примут нововведение с радостью, ведь для них это означало дополнительный контроль и добавляло работы. Чтобы сгладить отторжение, мы сначала четко проработали новые процессы и этапы перехода к новым стандартам, разработали набор информационных материалов и серию тренингов для сотрудников. Следующим шагом была официальная презентация, но не всем сразу, а сначала пилотной группе, обратную связь от которой предстояло обработать перед расширением охвата.

Для меня тогда было немного необычно, что иногда вместо настороженности мы встречали полное принятие и желание помочь, некоторых сотрудников новый подход к безопасности вдохновил: они задавали вопросы, давали обратную связь. Мы выбрали несколько человек из разных команд и предложили им стать security-чемпионами, то есть отвечать за security-review в своих командах. Некоторым из них их руководители (читай спонсоры) разрешили тратить часть своего рабочего времени на работу с безопасностью. Этого удалось добиться, объяснив руководителям все плюсы работы в новом процессе: ведь security команда не только предлагала процесс, но и обладала правом вето на выпуск релиза при наличии рисков, а рисками гораздо проще управлять заранее.

Маленькие локальные победы были достигнуты достаточно быстро, потому что пару человек мы начали знакомить с нашими подходами еще до полноценного старта проекта. Процесс постепенно перешел в другие команды и шаг за шагом достаточно масштабные изменения приняли во всей организации.

Весь спектр мотиваций

Но, конечно, не все реагировали на изменения одинаково. При внедрении любого проекте вы всегда встретите тех, кто саботирует новшества. По готовности воспринимать все новое, можно условно выделить 7 категорий участников процесса изменений.

  • В число миссионеров и визионеров входят топ-менеджеры и менеджеры, которые знают, зачем нужны изменения и продвигают их;

  • Активные последователи это Чемпионы. Они готовы работать по-новому;

  • Оппортунисты ищут личные выгоды и стремятся избежать личных проблем. Эти люди с радостью внедряют новые подходы, если они выгодны лично им;

  • Самая многочисленная группа равнодушные. Они предпочитают отсидеться и посмотреть что будет дальше. Такие люди, как правило, уже участвовали в изменениях, которые не увенчались успехом;

  • Бойцы сопротивления могут быть тайными врагами. Не говоря ничего в лицо, за спиной они будут обсуждать изменения в самом негативном ключе. Они кивают, когда выступает руководитель, а потом тихо саботируют весь процесс;

  • Явные противники выступают против изменений открыто. Они отстаивают свое мнение, и с ними очень важно общаться. Именно они могут указать на ошибки, недочеты и другие нюансы;

  • Эмигранты не поддерживают вообще никакие изменения.Они не видят перспектив в компании, и стремятся сбежать в любой сложной ситуации. Работать с ними практически бесполезно.

Когда вы продвигаете изменения, нужно четко понимать, с каким именно сотрудником вы имеете дело. От этого будет зависеть стиль коммуникации, а также методы контроля за выполнением требований. Конечно, проще разобраться, кто есть кто начиная внедрение в одном отделе. И поэтому мы в Acronis предпочитаем внедрять изменения постепенно.

Островной подход к внедрению изменений.

Островной подход к изменениям подразумевает внедрение новшеств в каком-то одном отделе или подразделении. Пилотный отдел можно выбрать произвольно, но хорошо бы, чтобы он в целом был склонен попробовать новый подход. Для того, чтобы явно выделить работающий по-новому отдел относительно других, его можно переименовать или брендировать, например, выдав корпоративные футболки.

Так, мое подразделение в Acronis в какой-то момент было переименовано из Performance QA в Performance Engineering, чтобы явно показать, что мы уходим от ручного тестирования производительности к более сложным автоматизированным решениям. В производстве, например, можно выдать людям белую униформу и назвать отдел Белым в контраст с остальными отделами, а может быть купить черные футболки и сделать спецов по безопасности Черной командой.

На этапе пилотного проекта обкатываются новые практики. Мы доводим их до состояния, близкого к идеалу. Дополнительным стимулом может быть повышение зарплаты сотрудников отдела, ведь это создаст позитивный конфликт между новым и старым, который будет подталкивать всю компанию к принятию изменений. Далее можно по цепочке реформировать остальные участки, постепенно переходя на новые процессы во всей организации.

Именно так мы строим новые практики работы внутри Acronis. Например, использовать Jira для контроля всех новых фич началось с нашей команды, а затем распространилось и на все команды с горизонтальными функциями. То есть изменения не обязательно должны идти сверху вниз или снизу вверх. Для них возможны разные направления, движения, которые зависят от конкретных людей и процессов.

Заключение

Так или иначе, внедрение изменений в любой компании это комплексная задача. Чем больше организация и масштабнее изменения, тем сложнее их реализовать. Но при должной подготовке, которая включает в себя поиск единомышленников, внутренний PR, подготовку быстрых побед, и с ней можно справиться. Главное помнить, что основной сдерживающий фактор для любых изменений это инертность человеческой психики. Поэтому, чем больше будет вовлечения, тем выше шансы на успех у любых изменений.

Подробнее..

Перевод Многие дедлайны придумывают специально с целью заставить инженеров работать бесплатно

26.09.2020 20:04:42 | Автор: admin
Работа инженера сплошное разочарование. Возможно, потому что у нас нет власти, а менеджеры сбрасывают на инженеров все проблемы и ожидают, что они будут решены к вчерашнему дню.

В большинстве случаев задачу поставил кто-то сверху, кто именно инженер не знает. Возможно, потому что менеджер хочет держать инженера в неведении или менеджер хочет держать своего босса в неведении. Бльшую часть времени задачи придумываются кем-то, кто понятия не имеет, о чём он просит и сколько времени это займёт.

Вот общий сценарий, который разыгрывается между инженером и его боссом, инженером-менеджером. Менеджер спрашивает, сколько времени займёт выполнение новой задачи. Бывает, что инженер не делал эту задачу раньше, поэтому честно отвечает, что понятия не имеет. Менеджер не принимает такой ответ и снова спрашивает. Тогда инженер даёт оценку практически наугад, а босс отвечает: Это слишком долго. Даже если инженер знает, сколько времени займёт выполнение задачи и даёт реалистичную оценку, менеджер часто отвечает: Это слишком долго. У тебя есть время до пятницы. Когда инженер спрашивает, как давно стало известно об этой задаче, босс отвечает, что месяц назад. Когда инженер спрашивает, почему он не сказал ему об этом месяц назад, тот просто смотрит на инженера, как будто не понимает вопроса.

Часто менеджер ставит невозможный дедлайн, например, три дня, чтобы решить проблему, которая, вероятно, займёт месяц. Это означает, что у инженера два варианта. Он может сделать некачественную (то есть паршивую) работу. Или может вернуться через три дня и сказать боссу, что работа не закончена. Очень часто, если он выбирает первый вариант, все счастливы, что есть какой-то результат, даже если это полный мусор, который абсолютно ни на что не годен. Если инженер возвращается через три дня и говорит менеджеру, что работа не завершена, его босс спрашивает, почему. Тот факт, что времени было недостаточно, не является приемлемым ответом. Но если работа всё же должна быть выполнена, инженеру дают больше времени. Подозреваю, что если работа изначально не была очень важной, босс просто говорит, что время истекло и нужно идти делать что-то другое.

Мне кажется, что такое взаимодействие между менеджером и инженером ни что иное, как игра. Либо для менеджера, либо со стороны компании. В первом случае это может быть демонстрация власти, а во втором реализация стратегии увеличения прибыли компании. Другими словами, если босс не совсем глуп (как иногда кажется), то он понимает, что инженер не может выполнить за три дня работу, которая занимает месяц. Но он играет по правилам компании: она хочет, чтобы инженер делал неоплачиваемую сверхурочную работу столько, сколько способен выдержать. Вот почему так много инженеров в некоторых компаниях работают по 70 часов в неделю.

Многие ИТ-компании фактически сдают своих инженеров в аренду клиентам по часам. ИТ-компании взимают плату за работу либо по количеству часов, которое потребуется для выполнения работы, либо по количеству инженерных часов, которые работа фактически занимает. Они берут с клиента плату за каждый час. Когда их инженеры работают бесплатно в течение долгого времени, это чистая прибыль для компании. Таким образом, у компаний есть огромный финансовый стимул, чтобы заставить инженеров бесплатно работать сверхурочно. В результате многие компании пытаются заставить своих инженеров работать как можно больше неоплачиваемых сверхурочных, даже если приходится придумывать фальшивые дедлайны.

Вы можете спросить, разве это законно? Да, это законно в Соединенных Штатах, поскольку инженеры получают фиксированную зарплату, а не почасовую оплату. Работнику выдают одинаковую сумму каждую неделю независимо от того, сколько часов он фактически работает. Почему это законно? Вероятно, это связано с тем, что крупные ИТ-компании могут позволить себе нанимать лоббистов, а инженеры нет.

Для Соединенных Штатов это означает, что многие инженеры перегружены работой и производят мусор. Когда ваш новый ноутбук умирает через шесть месяцев или в новом американском автомобиле через год взрывается прокладка головки цилиндра, причина может быть в этом. Жадные и эгоистичные компании заставляют врать и своих менеджеров, и инженеров. Они вынуждены говорить, что работа выполнена, когда она не выполнена, чтобы компания получила больше прибыли. Похоже, топ-менеджеров проблема не волнует. Вероятно, отчасти это объясняется тем, что большинство из них социопаты и психопаты. К сожалению, многие из наших компаний, по-видимому, стали оруэлловскими машинами, которые привели этих людей к власти, а оказавшись там, они порождают полный хаос для всех нас.
Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru