2. Нужно сказать о людях, что творчество в некоторых вещах — оно вредное. Они начинают заниматься не тем, чем должны заниматься — не поиском товаров, а перекладыванием цифр и оправданием того, почему у тебя это не получилось. Тут вопрос философский. Поэтому, с одной стороны, хорошо, когда у них низкий порог, и они начинают творчески подходить к этим вещам. А с другой стороны — это плохо, потому что у них должны быть готовые инструменты, готовые кейсы, с которыми они должны работать.
3. Если оценивать всю команду, наверное, процентов 40, даже не 40, а 30% владеют SQL и могут что-то написать, какие-то запросы сделать. Все остальное — это ручные операции, ручное сведение в Excel и т. д. Если 30% SQL, то, наверное процентов 10 из этого всего — Python могут написать, хороший какой-нибудь, закодить какую-нибудь штуку интересную. Ну, потому что, опять же — вопрос больше лежит в плоскости данных и возможности достать эти данные. Их долгое время не было. То есть они вручную просто выгружали — где-то из BI, где-то — из источника, из Axapta что-то грузанут. Соответственно, в полу-ручном режиме все это собирали, а навыков программирования — оно не прививается — пока у тебя не будет более или менее нормальной платформы, мы не начнем программировать.
4. Новых сотрудников мы уже стараемся подбирать с SQL и с Python. Ну, Python в меньше степени, потому что у нас. я не готов, я не понимаю пока, что они там будут питонить, потому что — собрать бы текущее и навести бы порядок в текущих данных, в текущих скриптах, которые существуют, и в текущих процессах. А потом только можно на следующий шаг пирамиды переходить, чтобы они могли что-то кодить, какие-то интересные вещи делать. Ну, то есть базовую отчетность не хочется строить на Python, хочется делать это на более friendly-инструменте, так скажем, — на Office обычном. Потому что Office пользуются, условно говоря, 90% компаний, а Python — ну, опять же, он не компилируемый, скрипт запускать можешь только ты, соответственно, все это обрастает внутри. То есть идем по пути того, что максимально широко потребляемо. Ты можешь в принципе этот Excel выгрузить, подключить, сделать подключение какое-то, обновлять — достаточно просто из любой точки компании. А Python — это уже некая такая проблема. Ну, то есть это реально про продвинутую аналитику, наверное, это уже чуть-чуть другой уровень, когда это внутри аналитического управления или департамента и какого-то отдела, и ребята уже начинают просто чуть глубже, чуть интереснее изучать данные и использовать их. У нас пока не та ступень.
5. Ну, ты базово берешь человека, который уже имеет какой-то опыт, и может развивать это направление самостоятельно. Ну, не знаю, ты берешь просто смарт-чувака, который может учиться и наращивать экспертизу. Какие-то внешние обучалки если ему требуются, это в зависимости от компании эти возможности включаются или не включаются. Человек либо будет обучаться этому дополнительно за счет компании или самостоятельно. Ну, в основном, все сами варятся в себе. Все эти компетенции — они там как бы наращивают опытным путем либо в интернете начинаем изучать что-то, самостоятельно опять же.
6. Сейчас как бы, ну давай скажем про customers support. Из-за того, что команда находится на…, как бы её уровень развития по data на очень низком уровне, культура работы с данными, наличие данных — она очень низкая. Поэтому и проектов особо нет. Очень много простоя и блокировки со стороны других людей, потому что я завишу от других людей, они моим продуктом пользуются. Всё равно какие-то вещи я делаю, потому что нужно готовится к сложным проектам, где-то ковыряешься, что-то там до сегментации пытаешься, где-то чему-то учишься. т. е. в общем, работы такого плана.
7. Самый простой пример, то, что мы сейчас пытаемся делать, — мы пытаемся оценивать качество работы IT специалистов. Причем там есть достаточно такая, понятная, острая, что ли, проблема, — это когда приходит новый человек, нужно во время испытательного срока, понять, насколько он тянет или не тянет, насколько он подходит или не подходит. И есть задача отслеживать работу, контролировать качество работы специалистов в целом, в компании. Для этого да, для этого мы собираем данные с Jira. В основном из Jira — это основной источник информации. Я знаю, есть приложения, которые, допустим, подключаются к гитам, например, и анализируют код, который анализируют разные параметры: количественные, качественные. Мы такое пока не делаем, не подключали такие сервисы. Но, по крайней мере, в Jira мы да, мы оцениваем
8. Первая проблема — это данные. Это и источники данных. А второе — это вообще дисциплина работы с данными сотрудников. Допустим, вот если мы берем такой показатель, как «попадание в оценку специалистом», то попадать в оценку можно двумя способами: первое — быть молодцом, то есть действительно делать задачи ответственно, быстро, хорошо, а второе — завышать оценки. Если мы работаем просто слепо, на уровне данных, то не всегда можно выявить, что вот этот попадает в оценку, а этот не попадает в оценку. А из (???) можно понять, почему попадает, потому что вот этот молодец или потому что он делает оценки в три раза выше и поэтому попадает, а так он хулиган. Понятно, что там есть разные способы с этим работать. Но первая проблема, или первая сложность — это, как раз, источники данных и доверие к данным. Насколько мы действительно этим данным, которые заведены, можем доверять. Вторая задача по сложности — это уже методология обработки и вот то, с чем мы столкнулись, это интерпретация: люди очень тяжело воспринимают данные. Им нужно как-то… Я для примера могу сказать: у нас такая простая штука, мы просто подключились к Jira и в Google Date Studio — мы вывели туда информацию по логам. Мы, допустим, хотели считать, наверное, знаешь такие термины: мат ожидание, дисперсию, вот эту функцию распределения данных попадания в оценку. Всё классно! Но 100 из 100 людей нифига не понимают эти термины и они смотрят, как баран на новые ворота, вот на этот график. Им надо попытаться прям на пальцах вот это рассказать. И то, как донести вот эти вот графики и данные до людей и как сделать так, чтобы люди смогли с этим работать и понимать эти данные, это, по-нашему опыту, оказалась тоже очень большой проблемой и задачей
9. Первое — это есть, грубо говоря, все мидлы — мидл программисты. И мы по всем мидлам определяем, в среднем, как они оценивают задачи. Второе, мы берем конкретного специалиста и сравниваем, как он оценивает свои задачи по сравнению с мидлами. То есть мы таким образом пытаемся выявить, не завышает ли он оценки. Третье — мы оцениваем, насколько он попадает в оценки, то есть считаем как раз вот это мат ожидания, строим нормальное распределение и считаем ширину этого нормального распределения, то есть насколько у него разброс. Допустим, попадает и у него разброс непопаданий небольшой, а этот оценил там в 2 часа, то у него 10 часов, то у него 5 минут и вот такое вот распределение широкое. Вот это основные характеристики, которые мы вытащили, которые мы оцениваем. Это конкретно работа с задачами, которые мы из Jirа тащим.
10. Когда вот эту задачу сформулировали, пошли смотреть, по каким параметрам, по чему мы можем контролировать специалистов. Выписали группы, разделили по параметрам, стали смотреть, каким образом можно отслеживать эти параметры. Большая часть, это процентов 90, — это, по сути, данные о работе, в основном из Jira. А дальше, когда начали смотреть считать, а как это делать, давайте мы посадим девочку, которая это будет делать. Но мы ахренели. Потому что эта девочка, она, во-первых, с ума сойдет от этой работы через какое-то время и уволится. А второе то, что у нас есть опыт вот такого делопроизводителя, который должен контролировать, что все сотрудники, логируют нужное количество времени. А здесь еще нужно учесть то, что мы работаем в разных Jirах, клиентские Jirы. И в итоге, не было ни одной недели, чтобы вот эта вот девочка, она не накосячила в этих выгрузках и обработках. То есть, первое, это сама по себе максимально тупая работа, которую только можно придумать, — найти человека под эту работу сложно. А второе — это то, что люди при работе с большими массивными данными постоянно ошибаются.
11. Давай отвечу сразу про сотрудников. То есть прям перформанс сотрудников — такого, наверное, пока не было. Я уже говорил, что у нас был операционный отчет, но там скорее нормы количества задач обращений, поделенное на количество сотрудников. Соответственно, растет количество обращений и кажется, что нужно больше сотрудников. Сама производительность сотрудников, насколько я помню, конкретно в той задаче не мерилась, но вообще, наверное, интересное направление.