Программисты делают бизнес

2021-06-07 10:03:12 #проkts
Требования для сеньоров

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

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

Мы решили начать с формализации требований к сеньору. В общем случае сеньор — это разработчик с большим опытом. Но что это значит? Мы накидали примеры того, что делает сеньор. У нас он, например:

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

Это то, что отличает сеньора от мидла, которому достаточно делать свои задачи хорошо.

Исходя из выделенных обязанностей, мы выстроим матрицу компетенций: в столбцах — грейды, в строках — компетенции, на пересечении — необходимые требования по конкретной компетенции для конкретного грейда. К компетенциям относятся как технические навыки, так и различные soft skills.

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

2021-06-04 19:20:19 ​​#проkts
Вебинар по курсу бэкенд-разработки на Python

Второго июня провели вебинар по курсу «Продвинутый backend на Python».
Это курс для джунов, которые хотят стать мидлами.

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

Подробно рассказали про программу:
– объектная модель в Python;
– метаклассы;
– утилиты языка;
– CPython;
– многопоточность и кооперативная многозадачность;
– Web;
– базы данных;
– тестирование;
– развертывание приложения.

Было много людей, много вопросов и в конце даже скептики остались довольны! Комментарии ниже

Посмотреть запись можно на нашем ютубе -



Курс начнется 16 июня.

До начала курса мы собираемся провести еще один вебинар — он будет 9 июня в 19:00 по МСК. Приходите, если у вас остались вопросы, ответим в прямом эфире.

Записаться на курс или следующий вебинар можно на нашем сайте - https://metaclass.kts.studio/backend. Открыть/Комментировать

2021-06-02 10:01:00 #проkts
Встречайте нашу следующую статью на хабре!

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

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

https://habr.com/en/company/kts/blog/560058/ Открыть/Комментировать

2021-05-31 10:01:00 #техника
Чек-лист вопросов, которые нужно решить перед внедрением

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

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

https://telegra.ph/CHek-list-voprosov-kotorye-nuzhno-reshit-pered-vnedreniem-05-27 Открыть/Комментировать

2021-05-28 10:01:00 #ментор
Как мы работаем с ментором

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

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

И мы не знали, как разорвать этот круг.

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

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

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

С начала года начали работать над брендом. Запустили канал в телеграме и блог на хабре (https://habr.com/ru/company/kts/), сейчас занимаемся разработкой фирменного стиля всей компании и оформлением кейсов.

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

2021-05-26 10:08:32 #заметки
Контент в соцсетях

На днях спорили с коллегами о том, какой контент должен быть в наших соцсетях. В «Телеграме» у нас канал с разными мыслями и полезными (надеемся) заметками. В «Инстаграме» отбитые фотки и офисные мемы. Кстати, обязательно подпишитесь (https://www.instagram.com/ktsmsk/).

И как раз по поводу «Инстаграма» мнения разделились. Раньше мы постили фотки сотрудников, офиса, разных мероприятий. Короче, было, как у всех. А потом решили транслировать наше истинное лицо

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

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

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

2021-05-24 18:03:28 #заметки
Можно ли формализовать ревью?

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

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

Наша HR настаивала на четких критериях для проведения ревью. Чтобы можно было однозначно сказать: да, этот человек готов к повышению. Но я считаю, что так формально собеседовать можно только на младших грейдах. Умеешь использовать библиотеки из списка, знаешь вот эти языки — повышаем.

А как оценить в цифрах самостоятельность, выбор оптимального решения, выбор архитектурного подхода и прочее?

Думаю, все это можно оценивать только субъективно, опираясь на свой опыт и представление о том, какими скилами должен обладать специалист на старших грейдах. Открыть/Комментировать

2021-05-21 18:01:00 ​​#заметки
История о почти сгоревшей жопе

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

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

Механике в одном из текущих проектов мы тоже изначально дали примерную оценку. Знали бы мы, что нас ждало…

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

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

Дали оценку, клиент ушел думать, а мы благополучно забыли о заявке.

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

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

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

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

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