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

2021-12-01 09:30:05 ​#размышления #сергей_чернобровкин

Краткосрочная мотивация

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

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

С процессами все намного сложнее.

Во-первых, результат сильно задерживается по времени.
Во-вторых, результата может не быть вообще.
В-третьих, даже если результат есть, непонятно — можно ли было сделать лучше?
В-четвертых, в новых направлениях много гипотез. Все они тратят кучу сил и энергии, но результат приносят только 5-10% из них.

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

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


Сталкиваетесь ли вы с такой проблемой демотивации от «долгих результатов» и как ее решаете? Открыть/Комментировать

2021-11-30 17:02:51 Channel photo updated Открыть/Комментировать

2021-11-29 11:26:06 ​#бизнес

Продажи

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

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

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

Но получать новые контакты надо обязательно. Весь KTS с самого начала был построен на репутации и сарафанном радио. Началось все с проекта для друга аспиранта, который вел у нас лабы — и дошло до крупных компаний типа VK, Mail.ru, ПИК, Сбербанк, Яндекс, Х5. Чем больше контактов, тем больше потенциал роста.

Поэтому мы определили этапы ведения заявки:

1. Почта. Отвечаем на письмо, рассказываем про процесс, договариваемся на созвон.
2. Созвон. Узнаем базовые потребности заказчика, понимаем его бюджеты и сроки.
3. Поверхностная оценка. Раньше мы сразу рассчитывали все очень детально, узнавали все подробности о системе и т.д. Такой подход занимает много ресурсов, а клиент, скорее всего, просто хочет получить ориентир. Поэтому теперь мы стараемся делать только поверхностную оценку для понимания — сходится она с ожиданиями клиента или нет. Конечно, тут нужен большой опыт, чтобы не ошибиться в несколько порядков.
4. Встреча. Если на первых этапах все ок, нужно назначать встречу и обсудить детали лично. После такой встречи мы близки к заключению контракта — клиент уже начал с нами активно взаимодействовать.
5. Составление коммерческого предложения. Узнаем детали проекта и формируем КП. Клиент уже работает с нами и, скорее всего, продолжит. Остается только сделать расчеты и приступить к работе.
6. Контракт. Финал. Подписываемся и стартуем.

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

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

2021-11-26 09:30:00 #хабр #максим_мялкин

Наш руководитель мобильной разработки Максим Мялкин опубликовал статью на Хабре:
«Мой опыт проведения курса по Android»

Вы когда-нибудь проходили онлайн-обучение? Два года назад Максим решил сделать курс для начинающих Android-разработчиков совместно с онлайн-платформой Skillbox.

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

Читать статью Открыть/Комментировать

2021-11-24 10:30:56 ​#маркетинг

Фэйл

Как вы знаете, у нас есть свой образовательный продукт — школа «Метакласс».

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

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

Каждую неделю мы постили тематическую статью на «Хабр», запускали рекламу со сбором заявок на вебинар, постили о нем новости в наши каналы и проводили вебинары в конце недели.

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

И вот по плану настал день бесплатного вебинара — просто о курсе, для всех. Мы собрали 40+ новых лидов (всего за месяц мы набрали 240+ заинтересованных человек). Но все пошло не по плану, и мы провалились везде, где могли.

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

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

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


А какие у вас были фэйлы, и как вы из них выходили? Открыть/Комментировать

2021-11-22 10:21:00 ​#развитие_сотрудников #сергей_чернобровкин

Про ревью

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

С самого начала, когда человек приходит в компанию, ему назначается наставник. Мы не используем слова «начальник» или «руководитель».

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

Ревью у нас состоит из нескольких этапов:

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

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

С этого года мы зафиксировали единый график ревью — январь-август. Так всем проще: сотрудникам — ориентироваться на повышения, а нам — планировать и проводить эту процедуру. Открыть/Комментировать

2021-11-19 09:45:13 #хабр #технологии

Наш фронтенд-разработчик Марк Садыков опубликовал статью на Хабре:
«Как не стать жертвой IT корпораций?»

«Данные пользователей — самое ценное для IT корпораций.

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

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

Например:

— NewPipe и FreeTube вместо YouTube
— Matrix вместо WhatsApp и Telegram
— F-Droid вместо Google Play
— и еще 6 других, а также небольшая историческая справка и общие рекомендации по безопасности»

За 2 дня статью прочли 13 000 человек. Прочтите и вы Открыть/Комментировать

2021-11-17 10:06:33 Открыть/Комментировать

2021-11-17 10:06:31 ​#развитие_сотрудников #виталий_черков

Конфликт архитектора и тимлида

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

— продолжить развиваться технически и стать архитектором
— прокачивать навыки управления командой, soft-скилы и стать тимлидом

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

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

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

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

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

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

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

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

А вы что думаете? Открыть/Комментировать

2021-11-15 10:27:51 ​#размышления #сергейчернобровкин

Сила 5 основателей

Отец всегда говорил мне: «Слишком много вас, учредителей».

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

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

К тому же каждый из нас уверен в компетенциях и мотивации других. Поэтому мы легко можем делегировать какие-то задачи отдельному человеку, а результат оценить вместе. Раньше мы это делали редко и «неспециально». А в этом году я ощутил настоящую силу от нашего количества учредителей — 5 человек в компании. Мы наконец начали разделять задачи и назначать ответственных.

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

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

Так что все не так однозначно, как может на первый взгляд показаться. Четкое разделение на «черное» и «белое» бывает только на картинках. Каждая ситуация, время и группа людей уникальна, и для каждого нужно искать сильные стороны, чтобы получилась синергия. Открыть/Комментировать