··• Серёжа печатает все посты канала

··• Серёжа печатает

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

··• Серёжа печатает

Потоки информации — ад, если не настроить. Две команды, в каждой из которых потоки информации сходятся ко мне. В зависимости от продукта или сезона, информации становится больше или меньше. Если правильно не настроить хаос, то умирал бы от информации. Что делать? Отсеять поток информации и оставить решения команде. Иерархия и карту потоков информации в команде. В отделе столкнулись с тем, что коммуникация свелась к одному человеку, которому стало тяжело. Нарисовали карту потоков информации — кто, к кому, с чем и когда, а главное куда идёт. Ради интереса делаем такую карту на компанию, чтобы найти проблемные моменты. Карта коммуникации — это не про вопросы, но и про ответственность. Сотрудник приходит к руководителю с рабочими и организационными вопросами, а до тебя доходят только сложные кейсы. Таким образом, при куче людей в компании, работаю непосредственно с шестью людьми, получаю информацию и помогаю принимать решения. Если бы не так, я бы сложился пополам. Настройка процессов — это первый шаг. Фильтруете объём информации, но она остаётся. И речь, в основном, про текстовую информацию. Но ещё встречи. Два продукта и календарь превращается в бесконечный поток встреч. Это круто, но когда надо работать руками, для этого надо найти время. Поэтому следующим шагом настраиваем себя. Первое — избавился от чатов, где не нужен. Не стоит пытаться знать того, что не касается сейчас. Нужная информация сама найдёт. Оставил 15 рабочих чатов. Это чаты команд, текущих проектов и каналы со смежными продуктами. Остальное в мьюте, настроено только на личное уведомление. Второе — настройка рабочего календаря. Блокировка утра и вечера, чтобы не ставили встречи до упора и выделение отдельного дня без встреч. Чтобы было время работать. Третье — режимы фокусировки в новой iOS, которая растекается по устройствам. Режим работа — никаких личных чатов, звонки от избранных, уведомления только из рабочих приложений. Режим личное время — звонки только от родителей и друзей, уведомления от приложений для жизни и развлечений, никаких уведомлений из рабочих чатов. Режим фокус — никаких уведомлений кроме звонков от избранных. Режимы растекаются по устройствам и информационный шум уходит. Четвертое — почта проверяется только утром. Днём не заходишь, если не попросят. Пятое — СМИ, медиа, статьи. Только утром, до работы и вечером то, что отложено на потом. Единственный кейс, который не решил — телеграмм, который перемешивает личное, рабочее, информационное и проектное. Разложить по папкам одно, а настройка уведомлений — отдельная тема. Пока двигаюсь в сторону того, чтобы убрать личные чаты и перевести в категорию работа.

··• Серёжа печатает

Когда команда делает по сорок проектов за месяц, возникает необходимость в контроле качества выполняемой работы. Мы прошли много этапов развития этого процесса. Я сам тестировал проекты, выписывал ошибки, отмечал замечания по коду. Потом случился первый тестировщик, который тестировал все проекты. С тех пор команда начала эволюционировать. Менялись подходы к тестированию, инструменты и даже то, что тестируем. Каждый раз, понимая, что недотестировали, пропустили, забыли — вносили корректировки в процесс и чеклисты. Растёт и число тестировщиков — уже 6 человек. Когда есть проекты с джунами, приходится тестировать много и часто, поэтому объём тестирования растёт вместе с Лигой. При этом много работы и с разработчиками. Учим проверять себя, чтобы отделу тестирования не приходилось заниматься тестированием очевидного. Пол года назад произошёл переломный момент. Клиенты стали приходить с запросом на тестирование других проектов, которые делали не мы, либо который делали мы, но прошли этапы интеграции и наполнения контентом. И решили выделили отдел тестирования в продукт, который будет работать как с Лигой, так и с другими клиентами на рынке. Так появилась Тестировошная — https://testim.agency/. Сфокусировались на тестировании интерфейсов, скорости работы и взаимодействия с пользователем. Так же развиваемся в сторону функционального тестирования и постепенно будем добавлять новые виды тестирования. В общем, превратили внутреннюю сервисную команду во внешний продукт, который будет развивать эту команду и давать ещё больше ценности Лиге.

Вдумчивое тестирование веб-интерфейсов.

Тестировошная

··• Серёжа печатает

Люблю стратегии. Когда только начинали, у нас были стратегии на год. После пары лет нереализованных стратегий, мы поняли — планировать дальше чем на пол года сложно и бессмысленно. Поэтому решили делать общую стратегию на год и частную стратегию на пол года. От этого больше толку, так как раньше, через пол года понимали что многие пункты стратегии уже не имеют смысла. Рынок меняется, компания меняется. К чему я? Команда только что закончили разработку новой стратегии до конца года. Это самая важная стратегическая сессия в Лиге с момента создания. По двум причинам. Первая — стратегию делали топ-менеджеры и руководители проектных отделов. Да, раньше стратегию делали в узком кругу на самом верху, а потом спускали вниз. При этом расписывали до деталей. Почему? У нас не было отдельных проектных отделов и руководителей, и подключать было некого. В этот раз мы определили только ключевые точки и показатели, а руководители сами продумали как будут к этому идти. Вторая — стратегия получила единый фокус и все действия направлены на этот фокус — сервис. Я всегда говорил — аутсорс это в первую очередь сервис, который предоставляет услугу. От фриланса нас отличает количество экспертизы и супер-высокий уровень сервиса. И наша задача на эту планку супер высокости залезть. На самом деле переделано будет очень много. От форматов представления информации для клиента, до скриптов, процесса сдачи и работы над проектом. В этом процессе задействованы все отделы и перед каждым стоит задача характеристика, которой мы этот уровень сервиса будем мерить. Могу сказать только одно. Когда компания растёт, это круто 😀

··• Серёжа печатает

Расскажу на каких принципах Лига переживала пандемию Вокруг говорили — это не первый наш кризис и мы знаем что делать. Для нас это был первый сложный период для компании и я не понимал как действовать. Проблема не столько в непонимании того, что делать прямо сейчас, сколько в том, что будет дальше. Не знаешь как будет реагировать рынок, какие будут последствия. Похожий момент был когда только начинал Лигу и тестировал гипотезы, но тогда на проекте не было команды из 40 человек, которые зависят от проекта. Самым главным решением было абстрагироваться от ситуации на рынке и сфокусироваться на текущих клиентах. Мы поняли — мы не знаем что происходит на рынке, но точно знаем что происходит у наших клиентов и можем вместе с ними продолжать работать, делая для них больше. Тут прям чуть не облажались, потому что делать больше не сразу смогли, а клиенты захотели сразу. Не без скрипа, но выделили внутри компании три проектных отдела, каждый из которых несёт свою функцию. Малая Лига — делает простые проекты и фокусируется на росте джунов рядом со штатной проектной командой опытных ребят. Это то, чем мы занимались до этого, и базой для этого направления стала Лига до пандемии. Большая Лига — делает сложные проект, при этом фокусируется на сервисе и улучшении проектов. Тут экспертиза, тут адаптив без адаптива и остальное. Мы до сих пор сталкиваемся с тем, что клиенты хотят ещё больше и ребята работают в эту сторону. Лига Фронтенда – как Большая Лига, только стек другой — React. Изменения основываются на принципе того, что мы сервис, часть которого пишет код. Помимо кода – клиентский сервис, готовность идти на встречу, закрытие большего объёма задач, экспертиза и образовательные активности для клиента. Мы проработали много процессов и механик на эти темы. Итог — вышли на больший объём бизнеса, на меньшем количестве клиентов, за счёт фокусировки на каждом. Конечно ищем новых клиентов постоянно, но принципы работы с новыми клиентами, как с постоянными. При этом оставили направление которое может помочь с простыми разовыми проектами и продолжаем работать в сторону помощи любому сегменту. p.s. я вроде включил комменты, но не понял работают они или нет)

··• Серёжа печатает

Принципы и опора руководителя в сложных управленческих решениях. Так называется круглый стол, на который меня позвала Настя Калашникова. Рассказываю про опоры принятия к сложных решениям, которые в Лиге приходилось принимать в прошлом году, когда бизнес мягко говоря трясло. Так как мы сервис, который обслуживает другие компании, если их поток запросов замедляется, работы у нас убавляется. Мы сделали много, чтобы нормально пережить этот период, и даже показали рост. Тем не менее сложных решений было достаточно — сокращение команды, отказ от дополнительных направлений и стажировок, жёсткое урезание маркетинга и фокус на текущих клиентах. Было заложено много крутых процессов, которые дали результаты и изменили компанию. Я буду рассказывать о них подробнее чуть позже, а сейчас про опоры. Принимать сложные решения — страшно. Но я опирался и опираюсь на следующие тезисы: — Необходимость принимать сложные решения. Вроде бы это очевидно, но осознание того, что необходимо принимать сложное решение упрощает принятие этого момента. — Сам продукт. Я уверен что решения в рамках моего продукта не смогут его прибить, пока я этого не захочу. Это такой godmod в рамках которого ты понимаешь что выстроил так, что он может увеличиваться и уменьшаться, но лопнуть просто не может. — Команда. Основа всего, но принимая сложные решения я понимаю что у меня есть люди, которые их примут и вместе со мной дальше продолжат развивать продукт. Разумеется, чем больше команда, тем больше будет людей, которые такие решения одобрять не будут и к этому тоже надо быть готовым. При этом это не означает что все решения будут правильные. Все ошибаются и через ошибки учатся. Но чем больше правильных решений, тем крепче продукт и тем больше доверие команды. Круглый стол будет тут — psiholog-anastasiya-kalas.timepad.ru/event/1…/1630265

ИТ-митап "После майских" / События на TimePad.ru

ИТ-митап "После майских"

psiholog-anastasiya-kalas.timepad.ru

··• Серёжа печатает

В последнее время мои образовательные усилия, направлены на коммуникацию между разработчиками и дизайнерами. Мы с Лигой уже четыре года выступаем в роли разработчика, которыей работает с дизайнами, и кейсов по неудачному взаимодействию достаточно. При чём вижу как и проблему со стороны разработчиков, так и со стороны дизайнеров. Проблемы кажутся не такими глобальными. Если всмотреться — разработчик и дизайнер потратили по часу времени на обсуждение момента, который кто-то не понял. Не так страшно. Но если смотреться ещё глубже — мы теряем время. Время лучше потратить на то, чтобы делать больше, лучше, интереснее или вообще что-то другое. У нас часто не хватает времени, чтобы вылизать продукт до конца, потому что в условиях ограниченных сроков, часть из которых тратится на бесполезную коммуникацию, невозможно доделать до идеала. Часть такой коммуникации происходит по той причине, что дизайнер и разработчик не воспринимают друг друга как часть одного процесса и не понимают друг друга на уровне работы, которую каждый делает. Разработчик не хочет вдаваться в принципы дизайна, он хочет чтобы дизайнер удобно и просто рисовал. Дизайнер не хочет вникать в базовые принципы разработки, он хочет просто увидеть в готовом виде то, что он нарисовал. При этом что значит удобно для разработчика, и что сделал дизайнер никто из них не задумывается. А те, кто задумываются и качают своих разработчиков и дизайнеров в обе стороны, получают прирост скорости реализации. Мы в Лиге наблюдаем — чем больше дизайнер идёт на контакт и общаемся с нами на этапе отрисовки дизайна, тем быстрее мы делаем нужный результат и получаем меньше претензий к этому результату. Не думаю что это совпадение. Сейчас я пытаюсь работать в этом направлении с дизайнерами. В какой-то момент стало понятно, что рассказывать об этом и говорить что давайте не будем так делать — не работает. Или работает не так, как хочется. Я представляю процесс обучения как — интерес, получение знаний, применение в реальной жизни. Поднять проблему, рассказать про неё и сказать давайте будем лучше — это интерес, на который есть отклик. Но до момента применения знаний в реальной жизни, их надо заинтересованной части дать. И тут уже сложнее, так как через доклады и разговорчики этому не научиться. Поэтому мы решили брать дизайнеров и учить их процессах, принципам и даже учиться кодить. При чём это делается как в рамках Лиги, обучая конкретных клиентов, так и я делаю это сам, запуская интенсивы по разработке для дизайнеров. А дальше будем думать про полноценную дизайн команду в Лиге, для того, чтобы получать максимум от взаимодействия между дизайнерами и разработчиками.

··• Серёжа печатает

Ребята сказали мне, что у меня накопилось интересного, чем можно поделиться, поэтому я решил канал вернуть. Я учёл прошлые ошибки, поэтому регулярности контента не будет, но зато будет более основательная проработка этого контента. Скорее всего многие отпишутся, но для тех кто останется напомню, что тут я буду рассказывать про Лигу, Академию, личные проекты и делиться мнением относительно того что я вижу. В ближайшее время будет новый контент. ❤️

··• Серёжа печатает

Ошибка #7 — ставка на начинающих специалистов Или, правильнее сказать, ставка только на начинающих специалистов. Опять-таки – это издержки растущего бизнеса, который не может позволить себе тратить много денег на начальном этапе. Однако очень сложно управлять командой, которая на 100% состоит из новичков, особенно когда внутренние процессы не до конца выстроены. Возможно, эта мысль со стороны кажется очевидной. Но когда я только начинал, мне так не казалось. Когда сталкиваешь с определёнными трудностями первый раз, не знаешь, как их решить. Проблемы: 1. Опытным специалистам надо больше платить, но что в таком случае делать с общими расходами компании, ведь они должны быть минимальны? Непонятно. 2. Как вообще мотивировать опытных специалистов, чтобы они выбирали маленькую начинающую компанию, взамен прежней стабильной и крупной? Непонятно. Первый пункт – это риск Важный момент, речь не идёт о том, чтобы каждый сотрудник был крутым экспертом, в команде должно быть несколько опытных специалистов. При выборе такого специалиста нужно думать не о размере его зарплаты, а о том, куда этот человек приведёт бизнес, и сколько он сможет заработать для него денег. А также, насколько он поможет с выстраиваем процессов и контролем. Второй пункт – это опыт Надо научиться находить рычаги мотивации крутых специалистов, определить пути развития для них внутри твоей компании. Например, для экспертов маленькое агентство может быть возможностью поработать на более высокой должности и получить более широкие возможности для реализации в профессии. Важно понять потребности того, кого вы хотите схантить, и попробовать их удовлетворить.

··• Серёжа печатает

Ошибка #6 — безостановочный, бурный рост компании Задача любой компании развиваться и становиться больше и лучше. Говоря о росте, я имею в виду рост, с точки зрения объёмов работ. Я работаю по принципу «ресурсов должно не хватать». И этот принцип мы освоили почти с самого начала Лиги, так как невыгодно нанимать специалистов про запас. Например, при команде, которая рассчитана на 10 проектов, мы выполняли 12 проектов, и так было на протяжении всего пути. Речь, разумеется, не о разработчиках, а о штатной команде, которая организует и обеспечивает их деятельность. При таком подходе команда увеличивается только тогда, когда становится уже просто невозможно работать эффективно. Разумеется, это контролируемый и планируемый процесс, всё не так страшно, как звучит. И, разумеется, это модель привела к ошибкам, некоторые из которых обошлись компании довольно дорого и болезненно. Если кто-то из членов такой команды внепланово уходит, мы получаем сразу два побочных действия. Во-первых, повышенная нагрузка на каждого из оставшихся: было и так под завязку, а теперь то, что, к примеру, делали три человека, распределяется на двух. Во-вторых, нужно срочно искать нового члена команды, это лишает возможности выбирать долго и тщательно, а значит, могут быть проблемы в будущем. Очень сложно разруливать продажи, особенно когда они быстро растут. Пару раз приходилось останавливать продажи или отказывать от 2-3 хороших проектов: мы не были готовы к этому объёму, а новый человек в команде ещё не появился. С другой стороны команда, которая рассчитана на 40 параллельных проектов, при 20 проектах начнёт высасывать денег больше, чем приносить. То есть компания уже не сможет позволить себе нормально существовать в низкий сезон, ей сложно будет проходить через кризисы. Если какие-то процессы работают недостаточно хорошо или требуют внедрения новых инструментов, это сложно делать на фоне высокой нагрузки. И чем больше в команде человек, тем сложнее эти изменения проходят. То есть у вас просто нет времени отдышаться, набрать воздуха и работать дальше. Изменения приходится вводить в режиме аврала. Люди выгорают на фоне нагрузки – это приводит к пункту номер один. Принцип «ресурсов должно не хватать» работает, если компания совсем маленькая и молодая, находящаяся на начальном этапе проверки бизнес-гипотез. Но дальше, скажем, если вы дошли до 3 года, нужно переводить нагрузку на специалистов в нормальное русло. Задача руководителя компании – держать в голове все риски, чтобы в случае их выстреливания не приключилось больших проблем.