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

Управление персоналом

Профессия СТО часть 2

13.01.2021 14:06:06 | Автор: admin

И: Что происходит, когда новый СТО приходит в компанию?

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

Интересный вопрос: а кто собеседует СТО? СЕО и его подчиненные. СТО - это такой мостик между теми, кто дает деньги, и теми, кто занимается разработкой, внедрением, имплементацией. Тебе надо сначала сформулировать свою картину мира, какие задачи и цели перед тобой стоят. Со 100%-й вероятностью то, что тебе говорит СЕО, окажется не так. Потому что то, какие задачи перед тобой ставят люди, которые тебя нанимают, скорее всего, это не совсем то, что им нужно - если бы они знали, что им нужно, им не нужен бы был СТО. Поэтому сначала требуется аудит и понимание того, что происходит. Для меня это прежде всего аудит людей, их возможностей, их потребностей. У меня был очень серьезный вызов - мне в подчинение достался человек, который был существенно старше меня и обладал - и до сих пор обладает - компетенцией, которой я не обладаю настолько глубоко. То есть я в институте проходил, как выглядит семиуровневая модель сети, но ниже истории с транспортным уровнем никуда не опускался. А тут есть человек, матёрый и опытный, и пришёл шпендель, который моложе его и не обладает компетенцией, чтобы им руководить, как ему могло показаться. Мой челлендж был понять, можем ли мы работать вместе и можем ли совместно приносить компании пользу. И мы, как мне кажется, завоёвывали взаимное уважение друг перед другом. Очень аккуратно присматривались, общались, пытались понять, на сколько мы в принципе говорим на одном языке. Нам это удалось, мы работаем вместе с 2012 года и тьфу-тьфу-тьфу вроде у нас всё хорошо.

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

А как выглядит собеседование СТО?

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

А как тебя собеседуют?

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

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

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

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

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

Можешь ли ты на каком-то уровне конкретики поделиться инсайдами о рынке СТО? Возможно, вилке медианной или что-то такое.

Вилки зарплат СТО примерно такие. Я не слышал о максимуме, но могу привести несколько примеров предложений, которые приходили мне. Я знаю, что сейчас зарплаты СТО начинаются примерно от 250 тысяч. Это мы говорим про компании не очень большого масштаба. В средней компании зарплата СТО сейчас, как мне кажется, около 450 тысяч. У гигантов побольше. Опять-таки, я смотрю по рынку по России. Если мы говорим про западные компании, история может отличаться, там роль СТО несколько более дорогостоящая. Но сейчас хорошие ценники болтаются около 700-800 тысяч. А дальше уже идут звёздные истории. Я знаю СТО с зарплатой в миллион, я знаю СТО с зарплатой полмиллиона, я знаю СТО с зарплатой 0,7 миллиона. И это всё довольно крупные проекты, которые на слуху.

Если взять какого-нибудь джуниор-разработчика и спросить его, кем ты хочешь быть через пять лет, он скажет: Я хочу быть СТО где-нибудь там. А что случается с амбициями, желаниями, планами, когда ты достигаешь этой точки? Что дальше?

Так совпадает, что люди выбиваются в сторону СТО примерно в районе кризиса среднего возраста или чуть-чуть пораньше - хотя я сильно до 30-ти начал заниматься управлением. Но по-хорошему, это просто жизненный вопрос: А что ты хочешь? Кто-то сильно упарывается по баблу. Идут в говнопроекты, где понятно, что то, что ты будешь разрабатывать, будешь разрабатывать в стол, и человек понимает, что оно никогда не полетит. Я знаю людей, которые в разные проекты ходят за деньгами. И когда они с помощью бонусных программ получают определенное value, они начинают не работать. Это один из путей. Второй из путей - когда ты переходишь в категорию бизнес-ангелов или инвесторов, людей, которые своим опытом и компетенцией помогают молодым компаниям пробиваться с технологической точки зрения. Тоже вполне себе интересная история. Этим славится определенное количество людей. То есть либо ты уходишь и делаешь свой стартап, либо ты просто помогаешь команде - за долю или ещё за что-то - которая тебе симпатична. Есть люди, которые продолжают переться от того, что они делают, и находить себе задачи и проекты, в которые они влюбляются. Я пока не разочаровался в том, чем я занимаюсь, и мне нравится то, что я делаю. Мне нравится заводить эти шестереночки и находить применение своим умениям. Плюс, есть два стандартных направления: вертикальный рост и горизонтальный рост. Ты можешь перепрыгнуть в компанию с большим штатом, с другими масштабами, ты можешь вырастить свою компанию - вариантов масса. А можешь пойти работать разработчиком, потому что, вы удивитесь, но в разных направлениях в большинстве случаев ценник заплат СТО не сильно отличается от зарплат разработчика или лида.

А что с опционами?

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

Подробнее..

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

20.01.2021 14:20:49 | Автор: admin
Собеседование инженера программиста сегодня часто включает в себя некий тест или упражнение на программирование, и я думаю, что это очень плохая вещь. Вот почему.




Ленивые тропы


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

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

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

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

Память


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

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

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

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

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

Общие задачи


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

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

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

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

Дискуссия. Дискуссия. Дискуссия


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

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

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

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

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

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

Подведем итоги




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

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

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

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

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

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



image



Подробнее..

Первый месяц с CRM собираем детские болезни проекта

20.01.2021 16:09:28 | Автор: admin
Для любых отношений, любого устройства и любой программы есть период привыкания отрезок времени, за который человек понимает принципы взаимодействия, разбирается в нюансах, находит свои фишки, определяет достоинства и недостатки и т.д. Так происходит с новыми коллегами, друзьями, новой работой, смартфоном, ноутбуком и т.д. Все мы когда-то испытывали это странное ощущение, состоящее из смеси любопытства, интереса, осторожности и лёгкого недовольства ведь человеческой природе вполне обоснованно неприятны перемены в окружающей среде.

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


Первые ошибки внедрения


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

  1. Компания не начинает работу в CRM-системе, пока не получит завершённый проект от вендора: с настройками, интеграциями и доработками. Это значительная отсрочка. Любая современная CRM изначально хорошо спроектирована: есть возможность вносить клиентов, создавать сделки и атрибуты сделок, звонить из интерфейса системы, отправлять почту, формировать профили продаж, создавать отчёты, заниматься персональным и коллективным планированием и проч (набор зависит от конкретной CRM-системы например, возможности разных редакций одной CRM вы можете посмотреть в таблице, это доступная функциональность из коробки). Поэтому откладывать использование системы чревато тем, что процесс затянется очень надолго, а когда вы начинаете работать сразу, вы со своей стороны мотивированы завершить проект внедрения как можно быстрее и уже работать на полных оборотах.
  2. Компания не проводит обучение сотрудников. Это странная форма экономии: обучение всегда стоит денег, но они несравнимо меньше стоимости внедрения (включая лицензии). Допустим, вы купили автомобиль, но не закончили автошколу. Вполне допустимо, что вы вместе с другом или коллегой разберётесь, как стартовать, ехать, тормозить и т.д. Но на дороге будет очень тяжело: знаки непонятные, правила передвижения потока неясные, гаишники ещё эти Путь к первоклассному вождению не будет закончен никогда, и это ещё ни слова не сказано о безопасности и ценности жизни. А тут три месяца отучился и всё, поезжай с потными ладошками, но с уверенными знаниями, это проще. С CRM ровно такая же история: если сотрудники знакомы с ПК, рано или поздно они разберутся и с CRM: формы, данные, отчёты, значки, подсказки никакого космолёта внутри не спроектировано. Но вот работать со связанными сущностями, понимать, как выбирать данные, создавать бизнес-процессы и т.д. не получится для этого нужно, чтобы эксперт показал основные принципы, объяснил, как CRM работает как система, а не как хранилище контактов. Освоить проще простого даже тем, кто с компьютером на вы, но игнорировать обучение нельзя.
  3. Компания чрезмерно форсирует старт эксплуатации CRM-системы. Ну вот представьте себе, компания малого бизнеса купила 10 лицензий RegionSoft CRM Professional Plus, потратила на это 153 000 р. (единоразовый платёж без аренды), ещё сколько-то планируется потратить на доработку. Руководитель хочет, чтобы инструмент начал окупаться на полную катушку и требует, чтобы сотрудники не просто вносили контакты и вели сделки, но и создавали бы бизнес-процессы, встроенные калькуляторы и проч. Сотрудники сразу раскалываются на три лагеря: первые (их мало) изучают интерфейс, документацию и работают изо всех сил, вторые (их мало) отчаянно ковыряют интерфейс и пытаются что-то слабать наудачу, третьи (их много) игнорируют CRM и ищут пути давления на руководство, чтобы отказаться от этой затеи (потому что им лень, им страшно, они не обучены и т.д.). Это чревато как конфликтами внутри организации, так и дисбалансом и низкой эффективностью самой системы. Старт эксплуатации должен быть постепенным, комфортным для каждого сотрудника в его собственном темпе и только при активном участии внутренних экспертов.

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

4 шага к решению проблем: чек-лист


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


Провести обучение и адаптацию сотрудников


  • Базовое обучение онлайн (или оффлайн) сессия знакомства с CRM-системой, демонстрация и отработка основных действий, разбор первых шагов и распространённых кейсов (завести клиента, задачу, сделку, настроить простой бизнес-процесс, отчёт и т.д.). Лучше, если первичное обучение проведёт компания-разработчик (вендор) CRM. Дополнительно можно запросить более глубокое обучение для внутренних экспертов, которые понесут данные дальше, сотрудникам.
  • Документация и мануалы отличный настольный материал для самостоятельного освоения CRM-системы, многие сотрудники предпочитают именно такую помощь в изучении новой программы. На Хабре мы сталкивались с довольно нестандартным мнением о том, что хороший софт в документации не нуждается. Нам понятно, что скрывается за этой фразой. Но для бизнес-ПО документация обязательна, поскольку это важный материал не для разработчика, а в первую очередь для конечного пользователя, который так себя чувствует увереннее.
  • Формирование базы знаний особые моменты и индивидуальные нюансы использования CRM в компании нужно вносить в базу знаний, к которой смогут обращаться в том числе новые сотрудники.
  • FAQ аналог базы знаний, но в формате вопрос-ответ. Создать его просто: все, кто задал вопрос по CRM и получил на него ответ, должны вносить их в файл. Из файла затем можно будет выбрать самые распространённые и сложные вопросы.
  • Внутренний эксперт человек (или несколько), который будет отвечать на вопросы сотрудников и консультировать их по использованию CRM-системы.
  • Адепты (early birds) CRM по-настоящему счастливый билет для компании. Если руководителю удастся выделить сотрудников, готовых нести идею CRM в массы и активно использовать CRM-систему с первого дня, внедрение будет практически беспроблемным. Адепты CRM сами донесут до коллег ценность программного обеспечения и покажут, насколько CRM упрощает жизнь. Чтобы усилия пошли в нужное русло, таких сотрудников можно дополнительно мотивировать.

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

Любая CRM это СУБД (набор связанных таблиц) внутри и интерфейс пользователя снаружи. Это всё, что пользователь должен знать о внутренностях. Интерфейс любой CRM представляет собой множество форм, таблиц и полей, заполнение которых наполняет те самые внутренние таблицы, к которым можно обратиться из любой части CRM (конечно, если она хорошо спроектирована мы на российском рынке CRM каких только чудес не видали).

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


Рабочий стол RegionSoft CRM

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


Карточка клиента RegionSoft CRM

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

Сделать первичную настройку CRM-системы


  • Системные и базовые настройки: списки сотрудников, реквизиты компании, настройки бухгалтерского и валютного учёта, вид рабочего стола и т.д. Лучше, если всем сотрудникам с настройками помогут 1-2 сотрудника, которые и будут верховными админами CRM, ответственными за корректную работу самого ПО, информационную безопасность и связанные с этим всем задачи.
  • Определение прав доступа: назначение прав доступа исходя из функциональных особенностей деятельности сотрудника. Это нужно сделать обязательно, поскольку назначение прав доступа один из важнейших моментов информационной безопасности внутри CRM.
  • Настройки почты: интеграция с почтовым клиентом или настройка почтового сервера для нативного почтового клиента (как, например, в RegionSoft CRM).
  • Настройки телефонии: настройка IP-телефонии, при необходимости виртуальной АТС.
  • Настройка отчётов: определение базовых отчётов, настройка фильтров, создание профилей воронок продаж. Здесь же настройка шаблонов и форм документов для печатных форм и отправки по почте (иногда шаблоны создаются с помощью услуг разработчика CRM или силами штатного программиста так быстрее и меньше ошибок).
  • Работа с планировщиками: настройка индивидуальных и групповых планов, создание и назначение задач, настройки среднесрочного планирования.
  • Наполнение справочников: создание необходимых для работы справочников (номенклатуры, транспорта, работ, услуг и т.д.).

Настроить интеграции


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

Настроить бизнес-процессы


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


Пример бизнес-процесса Доставка в RegionSoft CRM

Не бойтесь


  • Ошибаться и набивать шишки только таким путём можно вникнуть в самые глубокие дебри работы с CRM-системой и научиться её использовать на все 100% (это делают далеко не все). Наличие политик распределения прав доступа и бекапов надёжно защитят саму систему, а сотрудники, разбираясь в сложных конструкциях, научатся быстро и безошибочно работать с основным интерфейсом.
  • Задавать вопросы нормальный процесс. Их можно адресовать службе поддержки вендора, разработчику, внутреннему эксперту, владельцу (холдеру) процесса, коллегам. Вопросы и ответы как микросессии обмена информацией помогают каждому участнику процесса углубить и зафиксировать свои знания, улучшить практику использования CRM-системы.
  • Проектировать процессы и удалять их бизнес-процессы в CRM-системе одна из самых сложных функциональностей и вполне логично, что хочется их настроить раз и навсегда. Однако всё может получиться не с первого раза или хорошая идея по оптимизации процесса придёт позже тогда нужно брать и удалять всё ненужное, чтобы создать новый качественный процесс.
  • Рефакторить бизнес-процессы. Бизнес-процессы в компании постоянно меняются и это признак того, что она работает, развивается, меняет подходы в оперативной работе и т.д. Соответственно, вместе с реальными изменениями нужно вносить правки и в автоматизированные процессы, чтобы CRM была всегда синхронизирована с оперативной работой в компании.
  • Экспериментировать с подходами к CRM. CRM-система это инструмент не только отдела продаж, но и маркетинга, и сервиса, и, конечно, руководителя. Поэтому откройте доступ всем сотрудникам (не забудьте ограничить права доступа!), чтобы они могли использовать накопленную информацию в своей повседневной работе.

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

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



Мы готовы автоматизировать ваш бизнес с помощью универсальной CRM-системы RegionSoft CRM. До 31 января действует акция У нас минус скидка 10% на весь наш софт (а это не только CRM!). Внедряем, обучаем, поддерживаем качественно и удалённо. В новом году мы по-прежнему с вами.

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

Подробнее..

Статистика сертификации Института управления проектами (PMI) в России на 10.01.2021

17.01.2021 22:08:31 | Автор: admin

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

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


Итак, по состоянию на 10 января 2021 года, в открытом реестре PMI числится 1978 сертификатов и 1893 уникальных человека. Важно уточнить, что это количество людей, указавших своим местом жительства РФ и имеющих активный сертификат (он может быть не активен 1 год), не скрывшие их в настройках.

На сколько состав изменился?

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

Состояние сертификатов Состояние сертификатов

Продлено 1753 профессиональных сертификата, получено 342 новых, а также примерно 43 старых сертификата возобновлены и приостановлено действие (надеюсь, что временно) примерно 180 сертификатов.

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

Что касается изменений по годам, то картинка меня огорчила.

Сертификаты по годамСертификаты по годам

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

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

Наибольшие потери среди тех, кто сертифицировался 3 и 6 лет назад (цикл и два соответственно у PMI для сертификатов действует трехлетний цикл обновления).

Всего за 2020 год получено 339 сертификатов (и в подборку даже попали 3 сертификата, полученных в 2021 все три сертификата в этот раз отличаются от прошлогодних в этот раз это PMI-ACP, один из которых получил автор). В 2020 году получили:

в первом квартале 72 сертификата;

во втором квартале 46 сертификатов;

в третьем квартале 75 сертификатов;

в четвертом квартале 150 сертификатов.

И прибавка последнего квартала связана с изменением экзамена PMP, с 2021 года он обновлен и достаточно сильно (пусть пока в рамках PMBoK 6).

За этот год прибавилось:

15 CAPM;

299 PMP;

18 PMI-ACP (или 21 с учетом получивших сертификаты в 2021 году);

2 PMI-PBA;

5 PMI-RMP;

1 PgMP;

3 PfMP.

У нас на сегодня все так же всего 1 человек, обладающий 4 сертификатами. Обладателей 3 сертификатов стало 5, против 3 в прошлом году. И один из них стал первым в РФ членом малочисленного клуба обладателей PMP, PgMP и PfMP это Антон Субчев.

Людей, обладающих двумя сертификатами стало 74.

Результаты 2019 и 2020 годаРезультаты 2019 и 2020 года

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

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

Spoiler

Пирог сертификатов PMI

Динамика прироста PMP

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

Подготовлено на основании открытых данных, размещенных на портале PMI.ORG

Михаил Белов, PMP, PMI-ACP, ICP-ACC

PRINCE2 Foundation, PRINCE2Agile Foundation, ITIL4Foundation certified

Подробнее..

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

24.01.2021 16:23:06 | Автор: admin

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

Почему это стоит прочесть

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

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

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

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

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

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

Неудачи

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

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

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

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

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

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

Много работы

Я часто встречаю фаундеров, которые говорят, что работают по 16 часов 6 дней в неделю или 24/7, или другие вариации на тему полнейшей перегрузки работой. Мой собственный график основателя не поддаётся никакому анализу. Поверьте, дело не в том, что я безалаберный или бессистемный человек, это не так. Кто меня знает, может это подтвердить.

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

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

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

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

Демотивация

Здесь речь пойдет о мотивации, об отсутствии мотивации и демотивации. Последнее следует воспринимать как мотивацию с отрицательным значением. Все это связано с нашей физиологией, вернее с тем, как ее объясняет моноаминовая теория и с влиянием внешних факторов. Под внешними факторами в основном я имею в виду работу в состоянии неопределенности, высоки нагрузки и опять же неудачи. Если с неудачами и нагрузками мы как-то разобрались, то длительная работа в условиях поиска устойчивой бизнес-модели, рентабельного канала спроса, product-market-fit и прочего, что стартапы постоянно ищут, способна выбить из колеи любого. Даже если у вас кресло от Recaro в комфортном офисе возле дома.

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

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

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

Лидерство и рост

Если вы были топом в большой корпорации, то привыкли, что машина бизнес-процессов крутится будто сама по себе. Отвыкайте. Даже если вы инди-разработчик, кодер в именитой студии или даже в компании из FAGMA (Facebook, Amazon, Google, Microsoft, Apple) с огромным опытом, придется выполнять работу, которую вы раньше не делали.

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

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

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

Вывод 4: Запустить стартап это прекрасный способ проверить себя на прочность. Проверять на эту самую прочность вас будут все, кому не лень: конкуренты, команда, семья, партнеры, клиенты, инвесторы. Будьте готовы!

Не все так плохо

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

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

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

Подробнее..

Perfomance-менеджмент через оценки от идеи до бета тестирования

05.01.2021 14:11:03 | Автор: admin

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

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

MVP-версия продукта стартовала как Open Source решение и его развитие должно было происходить в свободное от основных задач время

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

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

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

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

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

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

Оценка - количественное выражение достижения команды, участника или отдела в целом. Мы решили, что два типа оценок для начала будет вполне достаточно:

  1. Качественная (soft skill) - оценивает качества разработчика или проект менеджера, например: умение найти общий язык, ответственность, пунктуальность и т.д.

  2. Техническая (hard skill) - оценивает работу с точки зрения технических знаний участника, например чистота кода, знание архитектуры и т.д.

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

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

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

Чтобы иметь возможность наблюдать продуктивность всей команды или собрать статистику по какому-либо проекту, были реализованы еще две сущности Команда и Проект. Пользователь с настроенной ролью может создавать проекты и формировать команды.

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

Backlog. В настоящий момент это список вопросов с радио кнопкамиBacklog. В настоящий момент это список вопросов с радио кнопками

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

За весь период разработки наше сообщество пополнилось. Проект стал интересен многим коллегам и они подключались в community. Кто-то уходил, а кто-то присоединялся.

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

Благодаря системе работа действительно стала намного прозрачнее.

  • Возможность выводить отчеты с результатами работы для начисления ежеквартальных премий

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

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

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

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

Бэклог в настоящий момент довольно огромный. Планируется запустить:

  • Функцию Спасибо, когда участник команды может вне задач благодарить коллег

  • Система достижений как элемент геймификации

  • Карма

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

  • Реализовать систему рекомендаций на основе данных, чтобы повышать определенные навыки

  • Градация роста по карьерной лестнице

Благодарности

От себя хотелось бы поблагодарить всех ребят из WRS Community, которые внесли и продолжают вносить вклад в развитие системы, а также компанию WOOPPAY, в которой я в настоящий момент работаю, за то, что положительно отнеслась к идее проекта и предоставила возможность провести бета-тестирование на одной из команд.

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

Большое всем спасибо!

Дополнительные материалы

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

https://github.com/wooppay/wrs/

Изображения персонажей ролей для статьи были созданы при помощи The Character Creator

https://github.com/ubik23/charactercreator

Рамки для изображений в статье были использованы из freepik.com

www.freepik.com/psd/mockup

www.freepik.com/psd/technology

Подробнее..

Перевод Маленькие задачи, а доверия ещё меньше

12.01.2021 12:17:05 | Автор: admin


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


Доверие высочайшая форма мотивации. Оно выявляет в людях самое лучшее.

Стивен Р. Кови, Семь навыков высокоэффективных людей

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

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

Наконец-то, у нас появился Винсент, я могу поручить ему заняться A и B; Тед будет делать C, D
и E, Джен займётся F, G и H, а я смогу добраться до I, J, K, L и M.

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

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

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

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

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

Так чьё это видение?


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

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

Слишком много любви к метрикам


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

К сожалению, мелкие задачи в Jira (или в любом из десятков других систем отслеживания ошибок) приносят с собой перспективу целого множества новых вкусных графиков и диаграмм: burn down, burn up, velocity, lead time, cycle time, task age, throughput, failed deployment, flow and control. Всё это манит, как ребёнка манит конфета.

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

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


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

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

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

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

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

Своим менеджерам они могут справедливо сказать: Это была твоя работа, не моя!

Оценка всегда требует ресурсов


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

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

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

Вывод


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

Я Америго, менеджер по продукту. А посему ни один разработчик не будет принимать проектные решения, ведь это моя вотчина.

А я Фернан, менеджер процессов. А посему ни один разработчик не будет принимать решений об организации процесса, ведь это моя вотчина.

Я, Бартоломеу, буду обеспечивать соответствие требованиям.

Я, Васко, неплохо разбирался в Microsoft Access, поэтому, наверно, буду заниматься базами данных.

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

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



На правах рекламы


VDSina предлагает мощные и недорогие VPS с посуточной оплатой. Интернет-канал для каждого сервера 500 Мегабит, защита от DDoS-атак включена в тариф, возможность установить Windows, Linux или вообще ОС со своего образа, а ещё очень удобная панель управления серверами собственной разработки. Обязательно попробуйте!

Подробнее..

Как не надо писать о себе в резюме

03.01.2021 02:10:08 | Автор: admin

Привет! Меня зовут Таня, и я IT-рекрутер. У меня набралось несколько отрывков из реальных резюме разработчиков, которые показывают, как не надо писать о себе. И я решила поделиться ими с вами. В конце каждого примера дан совет, как лучше рассказать о себе. Резюме были взяты с сайта hh.ru. Все имена и ссылки засекречены. Итак, поехали!

1. Слишком романтичное описание

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

Поэтому совет 1: минимум личного, максимум профессионального!

2. Слишком короткое описание

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

Совет2: кратко, но емко и желательно с фактами.

3. И швец, и жнец, и на дуде игрец

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

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

4. Вот вам ссылка на Гитхаб, вы сами все поймете (НЕТ)

Для этого случая у меня две новости хорошая и плохая. Хорошая новость: это описание лучше всех предыдущих. Плохая новость: шанс, что вас заметят, невысокий. Открою секрет: почти все IT-рекрутеры не понимают код. Максимум, что можно понять из Гитхаба на каком языке кодит разработчик, какие фреймворки использует, долгосрочность проектов и в общем-то все. Гитхаб будет полезен тому, кто курирует проект, на который ищут разработчика. Но чтобы попасть к этому куратору, вы должны пройти через рекрутера.

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

Заключение

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

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

Всем спасибо и пока!

Подробнее..

Перевод Мои доходы от работы очень хорошим инженером Facebook

05.01.2021 12:12:21 | Автор: admin
Когда я десяток лет назад переехал в США для работы в Facebook, то понятия не имел, хорошим или плохим был оффер. Я даже не торговался и согласился на ту сумму, которую мне предложили. Отчасти это вызвано тем, что я был в восторге от приглашения, отчасти тем, что я совершенно не знал, чего мне ждать. К своей чести, Facebook предложил мне на 78% больше, чем изначально (думаю, так получилось, потому что они ожидали, что я буду обсуждать условия, чего я не делал).

К счастью, в последние несколько лет благодаря сайтам наподобие glassdoor и levels.fyi стало очень легко узнавать средние зарплаты и их диапазон. Не хватает только одного информации о том, сколько можно зарабатывать, если ты по-настоящему хорош, допустим, входишь в 1% лучших инженеров FB (то есть на уровне примерно 100 инженеров). В этом посте я поделюсь своими зарплатами и карьерным ростом, чтобы дать представление о том, насколько быстро можно развиваться и как при этом будет меняться зарплата.

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

Ниже я расскажу о своём карьерном росте и зарплате, которую я получал, но если вам интересны только цифры, то вот таблица:


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

Первый год


Я устроился в FB как E4 с базовой зарплатой в 127 тысяч долларов и начальной долей акций на сумму 280 тысяч долларов. Facebook тогда экспериментировал со множеством новых продуктов и в компании была куча легко реализуемых возможностей. В первой половине года я в основном работал в качестве соло-разработчика, который очень быстро мог разрабатывать готовые к продакшену прототипы. За это время я создал 3 новых крупных фич/мелких продукта. Во второй половине года все три инженера-сениора, работавших над одним из важнейших продуктов в нашей области, ушли в другой отдел, поэтому я сказал своему менеджеру, что могу заняться этим продуктом. Из-за важности продукта за шесть месяцев в команде снова набралось четыре инженера, а поскольку я был первым, то стал техническим руководителем проекта.

За выпуск трёх фич и создание команды из четырёх человек меня повысили до E5 и выдали премию в 32 тысячи долларов (10% как уровню E4 и множитель оценки производительности 2,5), плюс дополнительный гонорар 112 тысяч долларов.

Общая компенсация: 229 тысяч долларов

Второй год


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

Из-за того, что мы продолжали делать продукт более успешным и собрали команду из десяти инженеров, меня повысили до E6 и дали премию в 56 тысяч долларов (15% как уровню E5 и множитель оценки производительности 2,5). Также мне заплатили дополнительный гонорар в 185 тысячи. Благодаря успеху команды и моей роли в нём мне дали дополнительную долю акций в 486 тысяч. Эта доля выдаётся сверх ежегодного гонорара и его получает всего 35% всех инженеров компании.

Общая компенсация: 304 тысячи долларов

Третий год


Я ушёл из своей предыдущей команды и с ещё двумя инженерами основал новую команду для повторного создания с нуля одного из важнейших продуктов FB. За 6 месяцев мы создали работающую версию и получили благословение руководства на дальнейшую работу. Мы активно начали рекрутинг в команду, и к концу года она выросла до 12 инженеров. Разработка продукта продолжилась, но в последствии выяснилось, что это была ошибка. Нам нужно было разрабатывать его итеративно, а не выпускать сразу крупномасштабным, как мы стремились.

Мне выдали премию в 60 тысяч (20% как уровню E6 и множитель оценки производительности 1,625), а также дополнительный гонорар в 200 тысяч. Благодаря наработкам, которые мы внесли в новый продукт, мне дали дополнительную долю акций на 860 тысяч.

Общая компенсация: 508 тысяч

Четвёртый год


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

Мне выдали премию 45 тысяч (20% как уровню E6 и множитель оценки производительности 1,125). За все годы это был самый низкий множитель производительности, я впервые вошёл в категорию соответствует требованиям. На этот раз никакой дополнительной доли.

Общая компенсация: 775 тысяч долларов (из-за повышения стоимости акций на самом деле в налоговой форме было указано больше одного миллиона).

Пятый год


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

Мне выплатили премию 47 тысяч (20% как уровню E6 и множитель оценки производительности 1,125), а также дополнительный гонорар в 225 тысяч. Учитывая то, что бОльшую часть года мы закладывали фундамент продукта, моя оценка оказалась ниже, но к концу года мы показали успешность, благодаря чему мне дали дополнительную долю в 907 тысяч и повысили до E7.

Общая компенсация: 750 тысяч долларов

Шестой год


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

Я вернулся к хорошим оценкам и получил премию 93 тысяч (25% как уровню E7 и множитель оценки производительности 1,625), а также дополнительный гонорар в 650 тысяч. Благодаря прогнозируемому будущему влиянию нашей работы мне выдали дополнительную долю в 816 тысяч.

Общая компенсация: 1,1 миллиона долларов

Год 7


В этом году наш продукт совершил настоящий прорыв. Его стали упоминать на совещаниях M-team (небольшой группы руководителей с которыми советуется Цукерберг) и он начал влиять на общие показатели Facebook. Команда увеличилась до 25 инженеров. Мы сделали ставку ещё на два новых продукта, один из них провалился, зато другой показал признаки успеха. Теперь у нас было портфолио из одного очень успешного продукта, одного умеренно успешного и одного перспективного.

Мне дали премию 78 тысяч (25% как уровню E7 и множитель оценки производительности 1,25), дополнительный гонорар 650 тысяч и дополнительную долю акций на 1,2 миллиона. Благодаря влиянию нашего продукта на доходы Facebook меня повысили до E8.

Общая компенсация: 1,3 миллиона долларов

Восьмой год и далее


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

В этом году мне выплатили премию 90 тысяч (30% как уровню E8 и множитель оценки производительности 1), дополнительный гонорар в 840 тысяч и дополнительную долю в акциях на 1,1 миллиона.

Общая компенсация за год 8: 1,5 миллиона долларов (из-за повышения стоимости акций на самом деле в налоговой форме было указано больше двух миллионов)

Краткая сводка за годы работы в Facebook:

  • В первый год я учился быть хорошим инженером,
  • Во второй год я учился быть хорошим техническим руководителем,
  • В третий-четвёртый годы начинал нечто новое с нуля. Хотя мы не добились успеха, зато узнали, как это делается
  • В годы с пятого по девятый я продолжал следовать модели третьего-четвёртого годов: начинал что-то новое, выпускал и совершенствовал продукт, а затем увеличивал масштаб, чтобы сделать его успешным.
  • В первые годы на мои успехи влияли мои навыки, удача и умение оказаться в нужном месте. Если бы три инженера-сениора не ушли из команды, то я бы не стал техруком так быстро, а потому был бы, по крайней мере, на один уровень ниже, а суммарные заработки в FB оказались на 25% меньше
  • В последующие годы в основном важна была моя способность раньше других находить новые возможности и хорошо их реализовывать.
  • Повышения с E6 до E7 и с E7 до E8 в основном были связаны с созданием чего-то успешного. Моя реализация могла быть идеальной, но если бы не успех продукта, меня бы не повысили.




На правах рекламы


Эпичные серверы это VDS для размещения сайтов от маленького интернет-магазина на Opencart до серьёзных проектов с огромной аудиторией. Создавайте собственные конфигурации серверов в пару кликов!

Подробнее..

Менеджмент будущего. Без начальников, переработок и KPI

05.01.2021 18:18:32 | Автор: admin

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

Кто такие Valve?

Valve Corporation американская компания-разработчик компьютерных игр. Автор хитов Conter-Strike, Left for Dead, Dota 2, создатель магазина игр Steam и очков виртуальной реальности Steam Index. Основана в 1996 году бывшими сотрудниками Microsoft Гэйбом Ньюэллом и Майком Харрингтоном.

В 2017 Forbes подсчитал, что основатель Valve Гэйб Ньюэлл с состоянием в $4,1 млрд. обогнал самого Дональда Трампа с его $3,7 млрд. При этом основной доход Ньюэлла составляет прибыль от магазина игр Steam, в том числе от покупок геймеров в Dota 2 и Counter Strike: Global Offensive.

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

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

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

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

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

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

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

Принцип 2. Выбери проект по душе или придумай свой

В компаниях типа Google сотрудникам дают право посвящать до 10% времени личным проектам. В компании Valve этот процент равен 100.

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

  • В каком из проектов я буду наиболее полезен?

  • Какой проект больше влияет на потребителей?

  • От работы над какими задачами я получу удовольствие?

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

Принцип 3. У столов должны быть колесики

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

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

Принцип 4. Право на ошибку

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

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

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

Принцип 5. Обратная связь всему голова

Как устроен карьерный рост в Valve? Как повышать кому-то зарплату в компании, где все равны?

В Valve существует два официальных способа оценки друг друга: рецензирование и ранжирование.

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

Ранжирование и оплата труда

Прибыль компании в пересчете на сотрудника превышает аналогичные показатели Google, Amazon и Microsoft. В связи с этим Valve считает справедливым платить своим людям выше рынка.

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

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

1. Профессиональный уровень/технические навыки

2. Продуктивность/результативность работы

3. Роль в команде

4. Вклад в разработку продукта

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

Принцип 6. Баланс работы и отдыха

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

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

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

Мы ищем людей, которые лучше нас.

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

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

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

  • Хотел бы я, чтобы этот человек был моим начальником?

  • Многому ли он меня научит?

  • Что будет, если этот человек начнет работать у наших конкурентов?

Принцип 8. Ищите Т-образных людей

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

Такой набор качеств ключевой фактор успеха в Valve: узконаправленный специалист плохо взаимодействует с другими сотрудниками. А работник-универсал, не разбирающийся глубоко в определённой области, практически не участвует в работе и как сотрудник едва полезен.

Принцип 9. Самофинансирование

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

Все права на интеллектуальную собственность также принадлежат Valve.

Valve это самофинансируемая компания. Ничто не мешает нам принимать собственные решения в отношении наших продуктов.

Слабые стороны Valve

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

  • Помощь новичкам в работе и наставничество

  • Распространение информации в компании

  • Поиск и прием на работу специалистов в совершенно новых сферах

  • Прогнозирование на период более 3-4 месяцев

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

Вопросы за кадром

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

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

На сайте по поиску работу Indeed всего три отзыва о Valve, и все они неплохие, средний бал 4,3:


Источники:

1. Официальный сайт Valve

2. Руководство для новых сотрудников на русском и на английском

3. Статья в Нью-Йорк Таймс

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

5. Страничка Indeed с отзывами на Valve


Для тех, кто предпочитает короткий жанр, автор ведет телеграм-канал@annakopyrneva, где пишет о софтскиллах, продукте и своей работе в ИТ.

Подробнее..

Recovery mode Как без стрессов перейти из новогодней праздности в рабочие будни?

09.01.2021 14:22:36 | Автор: admin

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

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

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

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

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

Подготовка к работе

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

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

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

Если правильно все спланировать, то не будет стресса: Шеф, все пропало, аврал, спасите, помогите.

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

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

Постепенный переход

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

Источник фото: pixabay.com

"Перегревы" на работе случаются как раз от непривычки.

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

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

Многое будет зависеть от того, как вы отдыхали на праздниках. Если контраст по темпоритму небольшой, то возвращение на работу пройдет комфортно.

Александр Кичаев

Подробнее..

Расширение технической команды в растущем стартапе проблемы и решения

12.01.2021 18:23:11 | Автор: admin

Один из интересных и не очень часто освещаемых вопросов ИТ-менеджмента расширение команды инженеров и ошибки, которые можно совершить на этом пути. Я сам активно развиваю свои проекты и поэтому интересуюсь этой темой. Мне удалось поговорить с Алиной Зурабовой, Head of Engineering and Testing в компании Smartcat. Этот стартап с российскими корнями, который развивает платформу управления переводами и привлек более $14 млн. Соответственно, за последние пару лет серьезно выросла и его техническая команда.

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

Введение: зачем понадобилось расширять команду

За несколько лет активной работы мы устаканили видение продукта, поняли, как именно он должен выглядеть хотя бы на текущий момент понятно, что все может меняться. Мы разобрались с тем, кто наши клиенты, какие у них боли и проблемы то есть нащупали, как говорят в США, product/market fit.

В частности, стало ясно, что наша модель это all-in-one-product, то есть мы хотим сделать систему, которая покрывает все бизнес-процессы пользователей разных ролей внутри индустрии переводов. Здесь есть и заказчики, которым нужно как-то получить перевод, и компании-поставщики таких услуг, а есть конечные исполнители, которые переводят контент. Мы хотим автоматизировать работу каждого участника этой цепочки.

При этом под капотом:

  • извлечение переводимого текста из файлов офисных форматов,

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

  • маркетплейс переводчиков (их умный подбор, тестирование и ранжирование внутри конкретного аккаунта),

  • поддержка мультиюзерного сценария работы внутри CAT-системы,

  • система биллинга и инвойсирования, работающая в интеграции с разными платежными провайдерами),

  • и т.п.

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

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

Урок #1: структура внутри команды не должна ограничивать рост

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

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

От этой модели при расширении команды пришлось отказаться по ряду причин:

  • звено менеджера стало бутылочным горлышком, bus factor начал зашкаливать;

  • выросло количество запросов к системе / пожеланий от пользователей;

  • наблюдалась потеря информации в узлах передачи информации от клиента к разработчиками;

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

Начали думать, как изменять модель, чтобы победить все эти сложности. В итоге (ничего нового я вам не открою) пришли к тому самому Scrum-процессу. Каждая команда отвечает за один из элементов цепочки продукт для заказчиков перевода, сервис-провайдеров или конечных исполнителей, задачи дробятся в рамках этих направлений (платежи, подбор исполнителей, отчетность и т.п.) Такую систему можно без проблем масштабировать и адаптировать под потребности бизнеса, да и потери и TTM (Time To Market) там меньше.Одним из важных шагов на пути прихода к такому сетапу стала книжка Hyper Growth, если бы знала о ней раньше могли бы пройти некоторые шаги и сделать открытия гораздо быстрее. В общем, да, рекомендую к прочтению всем IT-менеджерам, потом не забудьте сказать мне спасибо за 70 листов отборной полезной информации.

Урок #2: нужно четко планировать расширение команды и адаптировать процессы

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

Первый шаг на пути тестирования гипотезы all-in-one-product заключался в создании еще одного важного компонента системы маркептлейса исполнителей.

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

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

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

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

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

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

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

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

Урок #3: в стартап нужно нанимать особенных инженеров

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

Пойти на работу в Google могут многие, а вот сделать Яндекс самому это вызов совсем другого уровня. Оказалось, что этот тезис нужно отдельно доносить до инженеров.

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

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

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

Выводы: о чем помнить при расширении IT-команды в стартапе

В завершение, еще раз выделим ошибки и возможные решения:

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

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

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

Делитесь своими примерами трудностей при развитии технической команды в стартапе соберем максимально полный список проблем и решений в комментариях!

Подробнее..

2021 основные настройки

14.01.2021 22:19:16 | Автор: admin
2020 год смёл все прогнозы: кроме своих базовых опций, он нехило приложился к бизнесу. Пострадали не только официально пострадавшие отрасли: экономика штука взаимосвязанная, поэтому штормило всех, у кого-то был драматический рост, у кого-то не менее драматическое падение. Айтишникам повезло чуть больше остальных: мы входим в 2021 потрепанными, но живыми и готовыми к изменениям и новым вызовам. Этот пост небольшой традиционный прогноз того, что нас ждёт в новом году. В этот раз поговорим о том, что произойдёт с нашими специалистами в ближайшем будущем.


Малый бизнес выходит из 2020 в 2021

Что будет со специалистами?


Программисты


Среди языков программирования особых сенсаций в 2021 ждать не стоит: в топе Python, Java, JavaScript, Kotlin. По-прежнему сильные позиции занимают С и С++ это сложные высоконагруженные проекты, работа с безопасностью, наука, математические модели, компьютерное зрение и т.д. К сожалению, в последнее время наметилась нехорошая тенденция junior-ов после курсов, без базового технического образования: довольно взрослые соискатели обоих полов не понимают, из чего состоит проект, что такое бэкенд и фронтенд, чем дескоп отличается от веба и мобайла. Я молчу о паттернах, алгоритмах и структурах данных. И знаете, что? Онлайн-образование это классно, это доступно (относительно), это удобно, но это не всё. Да, можно стать программистом, прослушав длинный курс по JavaScript онлайн но только при одном условии: если это будет не работа на сертификат, а работа над своим проектом с книгами, Хабром и Stackoverflow наперевес. Всё остальное фикция, не дающая права требовать зарплату уровня миддла. Поэтому совет простой: выбирайте задачи и цели, под них выбирайте язык программирования и затем уже системно беритесь за обучение (с теорией и практикой). Иначе вы будете за бортом конкуренции.

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

  • английский язык сейчас он нужен практически в любой команде с той разницей, что где-то это технический английский для разработки и чтения документации, а где-то требование advance для общения с клиентами и международной командой;
  • понимание DevOps и DevSecOps направление будет развиваться всё больше и концепция любой разработчик немного админ и любой админ немного разработчик вполне возможно станет приоритетной уже к концу 2021 года;
  • софт-скиллы: навыки коммуникации, умение договариваться, обсуждать, встраиваться в бизнес-процессы это то, без чего уже практически невозможно стать senior-ом и выше;
  • понимание бизнеса, бизнес-процессов и основ функционирования компании станут огромным преимуществом, т.к. важно не просто сидеть и писать код или разрабатывать программы, важно управлять разработкой в соответствии с целями компании.

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

Системные администраторы


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

  • Займитесь облаками. Осваивайте топовые облачные платформы (Amazon Web Service (AWS), Google Cloud Platform (GCP), Microsoft Azure), панели, навыки работы с облачными сервисами из консоли. Да, мы как никто знаем, что корпоративная среда ещё долго окончательно не перейдёт в облака, но часть инфраструктуры давно живёт в них, а вам с ней работать.
  • Изучите основы ITSM, в том числе библиотеку ITIL. 2019-2020 обещали стать годами нового ITIL, новых подходов и лучших практик, но что-то нам всем помешало. Поэтому, скорее всего, трансформация начнётся весной 2021 и плавно перетечёт в 2022-2023. Среди лучших практик ITSM можно найти хорошие паттерны для любой инфраструктуры (даже очень маленьких компаний), но особенно вам стоит уделить внимание этому разделу, если вы видите себя CTO/CIO.
  • Учитесь работать с IoT (интернетом вещей). Мы ждали умный дом в каждый дом, умный завод и гениальный офис, но IoT пошёл развиваться в другом русле: он может встречаться в любом узле инфраструктуры, от видеонаблюдения до систем безопасности. Это крайне уязвимые устройства, поэтому сисадмин нового поколения должен понимать, как защитить эти системы от всех векторов атак.
  • Безопасность и мониторинг альфа и омега системного администратора. Атаки случаются со всеми и на всё: от собственных серверов и баз данных до облачных хранилищ. Задача сисадмина выстроить системы мониторинга таким образом, чтобы не реагировать на атаки, а предупреждать их. Малого бизнеса это тоже касается.

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

HR-специалисты


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

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

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

Маркетологи


В кризис рулят маркетологи, этот тезис измочален дальше некуда и, действительно, пиару и маркетингу уделялось огромное внимание во время кризиса 2008, 2014, 2018 годов. Увы, 2021 год не станет триумфом маркетологов, потому что они не успели вырасти вслед за новыми, сложными и небанальными вызовами. Сбит горизонт планирования, нет бизнес-целей, меняется спрос во всех сферах и потребительских сегментах. Уже сейчас гуру маркетинга заявляют о том, что бизнес должен стать более человечным, чем до пандемии. А до этого он был зверским, крокодильим, каким? Малый и средний бизнес давно понял, что клиент это основная ценность и именно он приносит деньги. А точнее, он обменивает деньги на ваши товары и услуги, включая поддержку, сервис и просто хорошее отношение. Кто этого не понимал до кризиса, уже проигрывали конкурентам и, скорее всего, уже проиграли окончательно.

Какие потребители нас ждут?

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

Работать в таких условиях достаточно сложно.

А что с удалёнкой?


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

Так что же будет?


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



Для большинства компаний малого и среднего бизнеса возрастёт роль автоматизации: корректный учёт клиентов и сделок, автоматизация бизнес-процессов и аналитика будут локомотивом, который будет активно двигать бизнес. Если вы не готовы стоять на месте (то есть катиться назад), мы готовы автоматизировать ваш бизнес с помощью универсальной CRM-системы RegionSoft CRM. Внедряем, обучаем, поддерживаем качественно и удалённо. В новом году мы по-прежнему с вами.

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

Олды в ИТ

18.01.2021 04:14:40 | Автор: admin

Когда ты молод, ты бессмертен и не задумываешься о старости. Есть просто уверенность, что если много и хорошо работать, то твоя карьера и доходы будут неуклонно расти. Следуя этой стратегии, ты развиваешься в профессии уже 15, 20, 30 лет. За эти годы уже получил огромный опыт и, наверное, он обязательно поможет безбедно и интересно прожить остаток дней. Но все не так просто. Да, ты уже давно работаешь в хорошей компании, занимаешься интересными проектами, получаешь за это достойную зарплату, но в будущем уже не так уверен, как раньше. Профессиональный возраст приходит с массой вопросов, на которые нужно ответь стратегически.

Эта статья родилась на основе обсуждения горячей темы Олды в ИТ, которую 4 января 2021 г. мы записали для подкаста Linkmeup. Обязательно послушайте запись здесь или в любимом подкаст-приложении.

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

Дисклеймеры

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

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

Контекст и проблема

Самое интересное - личные истории и подробности. Слушайте их в подкасте.

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

1. Конкуренция.

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

Важно. Я говорю об экспертах с опытом, скажем, 5 лет. Сравнивать начинающего со специалистом, конечно, глупо.

2. Устаревание знаний и навыков

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

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

3. Эволюционное угасание и смерть профессий

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

4. Неожиданные катастрофы

Оказывается, что термин VUCA (нестабильность, неопределенность, сложность и неоднозначность) придумали еще в 1987 г. Сейчас он опять популярен. Черные лебеди в нашем VUCA-мире случаются регулярно. Как глобально, так и на уровне отдельных людей. Ты или кто-то из твоей семьи может заболеть, компанию могут забанить на мировых рынках или она неожиданно разорится. Помните мировой кризис 2008 г.? В результате банкротства, на улице оказалось несколько десятков тыс. сотрудников банка Lehman Brothers. Включая самых мега-опытных и, казалось бы, защищенных ИТ-шников. Карьерный эскалатор иногда неожиданно ломается или везет вас не туда. Это нужно осознавать и, по возможности, быть готовым.

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

На сколько важны мировоззрение и картина мира?

Когда с профессионалами обсуждаешь их конкурентные преимущества по сравнению с более молодыми коллегами, они часто апеллируют к богатому опыту решения проблем, видению всей картинки в перспективе и технической эрудиции. Часто это называют Мировоззрением или Картиной Мира. Я согласен, все это важно. Только значимость Картины Мира, как конкурентного преимущества, сильно переоценена. По факту, это помогает исключительно вам. А вот как продать этот абстрактный и не понятно как измеримый и приносящий пользу навык, не очевидно. Представьте себе, вы приходите на собеседование, где соревнуетесь с молодыми, амбициозными и уже опытными спецами. Вас спрашивают: За что мы должные платить на 30% больше? Ваш ответ: Видите ли, у меня Картина Мира и вообще тонкое душевное Мировоззрение. Нет, так не работает.

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

В ИТ среде очень популярен мистер Вульф из фильма Криминальное чтиво. Возможно, вы тоже слышали: Я problem-solver, в нашей компании работаю Вульфом. Здорово, если так. Только мистер Вульф был крутым решателем проблем не потому, что у него была Картина Мира, а как раз наоборот. У него были конкретные скилы и репутация. О них мы тоже поговорим.

Возраст это недостаток?

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

CEO Facebook Марк Цукерберг когда-то сказал: Молодые просто умнее. Со-основатель Sun Microsystem и венчурный капиталист Винод Хосла с ним согласен: Люди младше 35 вот кто добивается перемен. В плане новых идей, люди старше 45 практически мертвы. Мне кажется, что много молодых ИТ-шников думают так-же. Я не собираюсь доказывать обратное. Просто хочу сказать, что возраст потенциально может повлиять на вашу карьеру. Многие топики и комментарии на Хабре подтверждают, что проблема эйджизма (дискриминации по возрасту) существует.

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

Какие скилы важны?

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

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

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

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

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

Если стратегический долгосрочный подход к хард-скилам чаще всего себя не оправдывает, то ситуация с софт-скилами обратная. Да, человеческий мозг нейропластичен до преклонного возраста, но новые связи образуются не быстро и для них нужно много разнообразной практики. CTO AWS Вернер Вогелс сказал: There is no compression algorithm for experience - Опыт не ускорить. Это особенно верно для софт-скилов. Работать над ними нужно долго, поэтому это стратегические инвестиции. Разумно в них вкладываться регулярно и не зависимо от того, нужны ли они вам прямо сейчас. Ведь такие навыки практически не теряются и не устаревают со временем.

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

Коммуникация это не только донесение информации, а еще и вызов какой-то эмоции. Чтобы пробудить деятельный ответ, нужно не просто понимание, но желание. Раньше говорили: Хороший человек - не профессия. В наше время хороший коммуникатор это уже профессия. И такой навык нужно тоже прокачивать. С каким количеством заказчиков вы можете поработать за 5 лет? Пускай, десятки. А за 20 лет это количество вырастет до нескольких сотен. И это проекты со своими особенностями, в непохожих компаниях, в разных странах, с разнообразными персоналиями. Здесь возраст играет на вас.

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

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

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

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

Как часто стоит менять работу?

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

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

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

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

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

Насколько важен авторитет старшего?

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

Артефакты бывают двух типов. Первый тип - те, которые можно показать. Сюда входят ваши проекты, статьи, записи выступлений на конференциях, и пр. Желательно, чтобы они были searchable, т. е. чтобы их можно было найти в поисковиках. Если вы работаете в больших корпорациях, часто проектные и даже некоторые личные артефакты публично показывать нельзя. В этом случае делаем ставку на результаты активностей вне основной работы pet projects, работа с комьюнити и т. д.

Второй тип артефактов те, о которых мы рассказываем. Это реальные истории ваших успехов, неудач, интересные случаи. Зачем нужно коллекционировать истории? Во-первых, они могут помочь вам в выстраивании первичных взаимоотношений с другими профессионалами. Здесь работает принцип свой-чужой. Интересному человеку с похожим опытом доверяешь больше. Я смотрю у вас на полке древний мануал по DUNIX для Альфы стоит. Классная система было. Вот помню, был случай Хорошая история оживит общение и поможет быстрее растопить лед приглядывания друг к другу.

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

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

Важно, чтобы в ваших историях были детали и, по возможности, конкретные данные и метрики успеха. Например, после выступления на хорошей конференции, организаторы обязательно дают вам информацию о количестве слушателей, рейтинге вашей сессии и отзывах участников. Это элементарное уважение к выступающему. Когда вы сами делаете демо или доклад, не стесняйтесь в конце попросить аудиторию ответить онлайн на один-два вопроса об эффективности проведенного с вами времени. Для слушателей это будет отличная возможность вас поблагодарить. Если вы хотите сделать артефактом результаты реального проекта, стоит избегать конфиденциальной информации: Крупный заказчик из индустрии A в результате внедрения B получил уменьшение/увеличение C на D%. Здесь уровень детализации вам подскажет здравый смысл.

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

Как бороться со звездной болезнью и токсичностью?

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

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

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

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

Иногда мы слишком персонально воспринимаем некоторые вещи. Принцип Бритвы Хэнлона утверждает: Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью. Часто мы просто накручиваем себя и проблемы банальной глупости и разгильдяйства возводим до уровня меня не ценят, а Солнце звезда, которая скоро потухнет. Если можете, расслабьтесь и забейте на это. Правда, для большинства совет расслабиться не работает и вызывает еще больший напряг. Тогда совет такой-же, как для звездной болезни. Уходите в другую команду или даже компанию. При этом не обязательно на новом месте, проблема, по которой вы колбаситесь, должна быть полностью решена. Часто сама смена обстановки действует благотворно.

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

Успешный ветеран обязательно начальник?

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

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

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

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

Какая быть готовым к Черным лебедям?

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

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

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

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

Когда можно сказать, что жизнь удалась?

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

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

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

Удачи!

Подробнее..

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

18.01.2021 12:13:17 | Автор: admin

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

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

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

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

Сравните два диалога:

Диалог 1

Руководитель: С кем ты целый день занимаешься?

Менеджер: ООО Ромашка, класс B.

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

Диалог 2

Руководитель:

С кем ты целый день занимаешься?

Менеджер:

ООО Ромашка. Мы им выслали коммерческое предложение, сейчас они хотят изменить часть заказанных наименований.

Крупный клиент?

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

Давно общаешься с ним?

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

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

Немного терминологии:

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

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

Скоринг клиентов CRM

Скоринг, так же как и грейдинг, система оценки каждого клиента. Разница заключается в том, то в скоринге оценка цифровая, и обычно оценок сразу несколько. Чаще всего в скоринге оценивают вероятность доведения клиента до продажи и возможную сумму, которую он может принести. Пример скоринга: вероятность сделки 15 %, прогнозируемая стоимость 1 млн, ценность потенциального клиента (лида): 1млн * 15 % = 150 тыс.

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

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

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

Пример

В компании средняя конверсия в продажи 20 %.Новый менеджер за месяц отработал 10 сделок и получил 5 продаж. Итого конверсия 50 %! Хорошо ли это? Оказывается, нет: средний чек составил 20 тысяч, и финальная сумма его продаж 100 тысяч. С точки зрения компании это убыток: минимально нужно продавать 200 тысяч. Опытный коллега отработал 50 сделок с конверсией в 20 % и средним чеком на 50 тысяч. Итого 500 тысяч, в 5 раз больше новичка!

Почему так вышло?

Новичок много сил потратил на каждого клиента, причём больше всего на тех, кто в итоге не купил. Средний чек у него невысокий, потому что лучших клиентов он запорол, не сумев предложить им оптимальный набор товаров и услуг. Опытный менеджер не только отработал в 5 раз больше сделок, но и выделил самых перспективных клиентов, сфокусировался на них и вывел их на максимальные чеки. С клиентами второго плана он работал значительно меньше. Другими словами, опытный менеджер сделал скоринг клиентов: разбил их по приоритетности и отработал максимально эффективно. Эффективность менеджеров удобно сравнивать в деньгах суммы продаж каждого за час его работы. Если оба отработали по 100 часов, то новичок принёс 1000 рублей в час, а опытный 5000 рублей в час.

Предположим, появляется клиент, который может заплатить 4000 рублей, и с ним нужно проработать 4 часа, то есть он даёт 1000 руб./час. Фирме такой клиент не выгоден, от него можно сразу отказаться. Как говорится, всех денег не заработаешь, не нужно гнаться за всеми возможностями сразу. Фокусируйтесь на тех клиентах, кто формирует основную прибыль компании. Это позволит обеспечить максимальный сервис именно для данного сегмента клиентов, и, как следствие, возрастут продажи и улучшится мнение клиентов о вас.

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

Какие факторы влияют на скоринг

1. Время

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

Пример: имеем 20-процентную конверсию сделок в успешные, в воронке 1000 открытых сделок, многие висят до года. Сколько из них приведут к продаже? Явно не 200, так как многие давно не актуальны. Параметр времени решает этот вопрос автоматически: скоринг укажет, что при средней конверсии 20 %, с учётом времени, из 1000 сделок ожидаем продажи, к примеру, только в 50 случаях.

2. Статус

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

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

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

4. Другие параметры

В скоринге можно учитывать различные дополнительные факторы: тип источника сделки, заказываемые товары, тип клиента, регион, есть ли выход на ЛПР, любые пользовательские поля. Эти же факторы используют и при расчёте прогнозируемой суммы сделки.

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

Пример расчёта скоринга

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

Вероятность по умолчанию: 20 %.

Время

Статус

Прогноз. цена1

Источник

Вероятность2

3Скоринг= ценность

Класс

ООО Ромашка

2 д

Встреча +30%4

50 000

site.ru

-15%

35%

17 5003

C

Тюльпан

30 д

-30%

Целевой

50 000

5%

2 500

E

Гладиолус

10 д

-10%

КП

+40%

100 000

сарафан

+30%

80%

80 000

B

Сбер

20 д

-15%

КП

+40%

500 000

Конфер.

+10%

55%

275 000

A

Администрация района

2 мес.

-60%

Встреча +30%

200 000

site.ru

-15%

5%5

10 000

C26

ИТОГО

Прогноз продаж 372 500

Важные классы, шт.: A=1, B=1, C=2

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

2 Здесь вероятность рассчитана по простой формуле сложения: базовые 20 %, плюс 30 % за встречу, минус 15 % за источник, итого 35 %. На самом деле, так суммировать и вычитать проценты математически некорректно (смотрите далее пример 6), правильнее использовать более сложные системы с учётом веса каждого фактора. Цель данной статьи показать возможности использования скоринга для CRM. Для информации о методах расчёта можно использовать публикации с деталям расчёта кредитного скоринга или использовать решения с готовыми формулами расчёта рейтинга клиентов CRM.

3 Показатель рассчитан как прогнозируемая цена, умноженная на вероятность. Для ООО Ромашка 17 500 это скоринг, он же ценность потенциального клиента в рублях, получен как 50 000 * 35 %.

4 Часть ячеек имеет показатель, влияющий на вероятность, например, +30 %. Если в ячейке такого показателя нет, значит параметр не влияет на вероятность. По умолчанию вероятность считается 20 %, этот параметр рассчитывается или указывается вручную для всех сделок, обычно для конкретной воронки в CRM (у разных воронок вероятность по умолчанию может сильно отличаться).

5 Если мы посчитаем вероятность простым сложением и вычитанием, то выйдет:

20 % - 60 % + 30 % - 15 % = -25%. Конечно, у любой активной сделки вероятность более 0 % и менее 100 %, и в данном случае будет примерно 5 %, если считать по сложной правильной формуле.

6 С2 цифра 2 означает, что клиент ранее занимал более высокий статус, но со временем снизился до класса C. В CRM удобно хранить наивысший класс или рейтинг клиента, чтобы видеть всех клиентов, по которым было значительное снижение. Класс клиента показатель на сегодняшний день (он может повышаться или понижаться со временем).

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

Прогноз продаж 372 500

Важные классы, шт.: A=1, B=1, C=2

Если на входе будет не 5 сделок, а 5000, и параметров для расчёта скоринга будет не 3, а 10, то финальные строки ИТОГО будут содержать всё тот же небольшой объём информации, который можно оценить за несколько секунд.

Методы работы с клиентами классов A..F

Клиенты класса A

Самые крупные и перспективные клиенты.

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

Клиенты класса B

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

Именно в этом сегменте происходят основные продажи. Руководитель за ними следит, используя средства CRM.

Клиенты класса С

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

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

Класс C удобно разделить на два подкласса:

C1 новые клиенты;

С2 клиенты, которые скатились в класс C из B и A.

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

Клиенты класса D

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

Клиенты класса E

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

Клиенты класса F

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

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

Пример: менеджер по продажам в ответ на запрос клиента переслал письмо технического специалиста, написанное сложным языком. Клиент ничего не понял и ушел, хотя технарь дал полезный комментарий просто не хватало картинки и понятного описания. А вот при общении с клиентами класса B та же недоработка воспринимается проще, так как клиент уже привык и готов прощать незначительные проблемы в коммуникациях. Другой пример ошибки в классе C: менеджер до упора отрабатывает клиента, а тот давно уже пользуется таким бесплатным консультантом, но покупать ничего не будет, особенно если он не ЛПР (лицо, принимающее решение).

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

Посмотрите на следующие два варианта оценки компании. Где состояние продаж стабильнее? В скобках даны прогнозы продаж по сделкам каждого класса.

Вариант 1

Прогноз продаж 100М (100 млн )

Важные классы: A=5 шт. (50М), B=100 шт. (20М), C=500 шт. (20М)

Вариант 2

Прогноз продаж 100М

Важные классы: A=5 шт. (20М), B=100 шт. (50М), C=500 шт. (20М)

Все показатели идентичны, разница только в том, что в варианте 1 половина всей ожидаемой выручки приходится на клиентов класса А, а в варианте 2 на клиентов класса B. Стабильнее ситуация во втором варианте, так как ожидаемые суммы распределены на большее число клиентов. Здесь на 100 клиентов класса B приходится половина ожидаемой выручки, 50М. В первом варианте половина ожидаемых продаж приходится на клиентов класса A, которых всего 5. Это значит, что если со всеми пятью возникнут проблемы, то фирма не сможет получить половину ожидаемой выручки. Стабильность это устойчивость к стрессам, которая тем выше, чем меньше зависимость от каждой конкретной сделки.

Общие проблемы CRM, которые неожиданно просто решает скоринг и грейдинг

Наша компания Nemind специализируется на анализе данных Битрикс24 и amoCRM. Общение с сотнями клиентов позволило выделить общие для многих проблемы. Хотя все наши клиенты серьёзно относятся к ведению CRM, вопрос удобного контроля со стороны руководства является актуальным и трудноразрешимым. Один генеральный директор компании так описал проблемы управления компанией при помощи CRM:

ДАНО

CRM ведётся 1,5 года, в ней несколько сот открытых сделок разной длительности. Средняя продолжительность успешных сделок от 2 месяцев до 1 года, средний чек около 15 миллионов. В компании три менеджера по продажам.

НАДО

Понять, хорошо ли идут дела? Быть может, всё плохо, и скоро фирма окажется без заказов? Какие заказы, и главное какие суммы продаж мы прогнозируем на ближайшие месяцы?

Нужны ли ещё продавцы, или имеющихся менеджеров достаточно?

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

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

Хорошо ли идут дела? Вдруг фирма скоро останется без заказов?

  • Изучаем динамику изменения количества сделок классов B и А. Если их становится больше хороший маркер, если меньше плохо. Нужно работать с маркетингом и изучать сегмент C: насколько грамотно отрабатываются сделки сразу после создания.

Какие суммы мы прогнозируем на ближайшие месяцы?

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

Нужны ли ещё продавцы, или имеющихся менеджеров достаточно?

  • Смотрим распределение сделок и времени менеджеров по сделкам разных классов.

Всего сделок открытых

Сделок класса A

Сделок класса B

Сделок класса C

Время на сделки классов D, E, за мес.

Иванова

100

0

2

23

20 ч

Петрова

90

2

4

17

10 ч

Смирнова

80

1

1

28

15 ч

Если менеджеры тратят более 20 % времени на клиентов классов D и E, значит времени у них более чем достаточно. В представленном примере видим, что Петрова потратила всего 10 часов за месяц на эти сегменты, значит она перегружена. Совет: если невозможно точно подсчитать потраченное на клиента время,, учитывайте его приблизительно, по количеству задач, звонков, писем и других дел, связанных с данной сделкой.

У Петровой 2 клиента класса A и 4 класса B, а у двух других на двоих всего четыре клиента этих классов. Петрова, скорее всего, перегружена важными клиентами. Возможно, она лучше работает, ведёт клиентов дальше и на большие чеки, потому не хватает времени на клиентов класса C. Но фирма может потерять деньги из-за возникшего дисбаланса. Обратите внимание, общее число открытых сделок у Петровой среднее 90 шт. И лишь сегментация по классам позволяет сделать выводы о перегруженности конкретного менеджера.

Инструменты настройки скоринга и грейдинга

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

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

  3. Расчеты с использованием бизнес-процессов, триггеров, автоматических калькуляторов. Хорошее решение, которое позволяет не просто автоматизировать скоринг и грейдинг, но и учитывать особенности конкретной CRM. Главная проблема сложность создания и особенно редактирования таких решений. Если в бизнес-процессе прописывать условия на каждый статус, каждый сегмент, каждый диапазон времени, учесть источники и типы продукции, то этого достаточно, чтобы в Битрикс24 бизнес-процесс вырос на десяток экранов. И это без учёта вывода в пользовательские поля метода расчёта скоринга. С другой стороны, если алгоритм скоринга прост, то использование бизнес-процессов является быстрым и эффективным решением.

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

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

Проверка скоринга

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

Пример

ООО Тюльпан, ценность 12 000.

ООО Ромашка, ценность 10 000.

Менеджер изучает сделки и решает, что Ромашка должна быть ВШЕ по приоритету, чем Тюльпан. На основе его объяснений и аргументов составляется техническое задание на изменение алгоритма расчёта.

Детали скоринга. Что нового видим в карточке сделки?

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

Пример шести заполненных пользовательских полей в группе сделки Скоринг:

Класс: B

Ценность: 60 000

Вероятность: 60%

Снижение ценности от максимума: 5000

Прогноз цены: 100 000

Детали скоринга:

базовая вероятность 20 %, статус предоплата получена +45%,

длительность 7 дней -5 %. ИТОГО 60 %.

Базовая сумма 50 000, Лицензия Enterprise +40 000, Самара + 10 000.

ИТОГО 100 000

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

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

Добавить класс с типами +1 и -1. Если руководитель поставит в примере выше

Добавить класс +1, то сделка, которая рассчитана как класс B, автоматически станет классом A.

Как я изучаю незнакомые сделки в CRM

При изучении ситуации в CRM, я, как руководитель, пользуюсь следующими приоритетами:

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

  2. Читаю комментарий мы используем такое поле в сделке для краткого изложения личного мнения менеджера о сделке. Там находится ответ на вопрос что с этой сделкой?, поэтому нет необходимости каждый раз спрашивать мнение менеджера. Иными словами, я всегда знаю мнение каждого менеджера по каждой сделке (ответ записан в комментарии, 12 предложения). Реальные примеры: Попросила продлить ознакомительный ключ в связи с новогодними праздниками. Дали ключ до 22 января, Требуется расчёт конверсии по своей формуле. Как только происходит важное изменение в работе со сделкой, менеджер меняет комментарий.

  3. Дальнейшее направление изучения сделки зависит от того, насколько она мне интересна.

Такой подход позволяет экономить время руководителя при анализе CRM и меньше отвлекать менеджеров.

Классификация постоянных клиентов

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

Заключение

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

Подробнее..

Перевод Определение технического лидера

18.01.2021 18:09:31 | Автор: admin

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

Определение

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

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

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

 Команда с Product-менеджером, инженером-менеджером и техлидом Команда с Product-менеджером, инженером-менеджером и техлидом

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

 Команда с Product-менеджером и техлидом Команда с Product-менеджером и техлидом

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

Что остается в любой команде несмотря на ее состав это техническое превосходство техлида. Эффективный техлид работает над техническим видением команды. И вместе с командой они обновляют, развивают его и претворяют в жизнь. Техлид постоянно работает с кодом, чтобы принимать обоснованные решения, выявлять технические риски и выстраивать доверительные отношения с разработчиками. В своей презентации The Geeks Guide to Leading Teams я предлагаю проводить над кодом минимум 30% времени.

Не просто тимлид

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

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

Больше практики, чем у инженера-менеджера

Вы управляете вещами и руководите людьми.

- Грейс Хоппер

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

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

  • Выбивают бюджет на развитие и поддержку бизнес-целей;

  • Представляют технологические перспективы на уровне руководства или совета директоров;

  • Создают или координируют рабочие программы (реализуемые в рамках разработки);

  • Занимаются рекрутингом и удержанием персонала для удовлетворения потребностей команды или ИТ-персонала.

Инженер-менеджер может быть как одним на команду, так и одним на несколько команд. У многих из них может даже не быть опыта разработки. Вместо этого они могут быть Product-менеджерами, QA или другими специалистами, вовлеченными в разработку ПО.

Техлид хороший архитектор

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

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

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

Какими ключевыми навыками должен обладать технический лидер?

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

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

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

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

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

- Определения техлида (от @patkua)

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


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

Ответы на эти и многие другие вопросы даст эксперт OTUS - Александр Пряхин, в рамках бесплатного демо урока курса "Team Lead 2.0". Записывайтесь на урок по ссылке.


Подробнее..

В Reddit через PayPal и Alibaba без релокации и смс

20.01.2021 20:22:57 | Автор: admin

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

Мы нашли человека, который построил впечатляющую карьеру в IT, принимая нетипичные решения. Он уходил от инженерных задач в управленческие, его карьеру не назвать ни вертикальной, ни горизонтальной. Backend Engineering Manager в Reddit Максим Алексеев поделился опытом работы в PayPal и Alibaba.

За 17 лет в IT Макс побывал тимлидом и техлидом, консультировал компании Кремниевой долины в области распределенных кешей и дата-гридов, отвечал за бэкенд, DWH, ML и руководил стартапом SCORR.

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

Определяющее решение настарте. Grid Dynamics

Максим начинал инженером: кодил наJava, Scala, Python, затем Kotlin. В2011 собеседовался сразу вдве компании: вхорошо оплачиваемый системный интегратор ивмосковский офис Grid Dynamics. Предложение Grid Dynamics было вдва раза менее денежное, нозадачи итехнологии намного интереснее. Максим выбрал задачи инепрогадал. Grid Dynamics работали сновыми технологиями, которые позже становились мейнстримом. Было много проектов наоптимизацию распределенных систем уклиентов под еще больший трафик инагрузки, нередко использовались публичные иприватные облака. Позже такой набор задач исопутствующих технологий стали именовать highload. Так выбор впользу меньшего посумме оффера оказался более удачным.

Grid Dynamics лидер вобласти технического консалтинга. Поэтому всилу специфики работы Максиму приходилось ездить вСША. Самая короткая подлительности командировка вСанта-Монику заняла пять дней, асамая длинная полгода вкампусе PayPal вСан-Хосе.

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

Бодишоп: хорошо или плохо?

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

  • появляется возможность переехать вдругую страну;

  • это отличная практика иностранного языка;

  • можно набираться разнопланового технического опыта;

  • есть опытные коллеги укоторых можно многому научиться;

  • вфирме хорошо налажены бизнес-процессы.

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

Поэтому лучше быстро набраться опыта иследующим шагом выбрать продуктовую компанию. Здесь плюсы очевидны:

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

  • всегда есть идеология продукта;

  • мотивацию сотрудников подогревают существенными бонусами ивознаграждениями.

Многие русские коллеги Максима поGrid Dynamics успешно переехали вСША. Максим тоже получил предложения оработе вКремниевой долине, нотогда отних отказался.

Стоит ли соглашаться на переезд любой ценой?

В2012 Grid Dynamics закрывали офис вМоскве ипредложили два варианта релокации: впитерский или американский офисы. Чуть раньше Максиму поступило заманчивое предложение напрямую отPayPal. Мечта разработчика сбылась? Возможно. Ноонпризадумался ивыбрал другой путь.

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

Кампусы IT-компаний оборудованы навысшем уровне, работать вних комфортно икруто, номалоэтажная жизнь оказалась слишком скучной после мегаполиса. Любимым развлечением там были поездки наприроду, вэтом смысле Америка бесспорно великолепна. Путешествие попарку Йосемити запомнилось Максиму навсю жизнь. ВСША стоит поехать как минимум, чтобы посетить Редвуд иЙеллоустоун. Новсамих апарт-комплексах Долины ему было нечем заняться: нехватало ощущения хоть какой-то городской жизни.

Жить вСан-Франциско былобы интереснее, ноэтот вариант проигрывал сфинансовой точки зрения. Калифорния один изсамых дорогих штатов вСША. Поданным сайтаGobankingrates.com, еежители тратят нажизнь всреднем на35% больше, чем жители других штатов.

ПоданнымNumbeo.com, стоимость жизни вСан-Франциско такая:

  • Ориентировочные ежемесячные расходы семьи изчетырех человек без арендной платы 323 372,77 (4366,36$).

  • Ориентировочные ежемесячные расходы наодного человека без арендной платы 89 077,47 (1202,77$) .

  • Индекс стоимости жизнивСан-Франциско на126,98% выше, чем вМоскве.

  • Аренда вСан-Франциско всреднем на314,63% выше, чем вМоскве.

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

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

Изинженеров вдиректора. Плюсы работы встартапах

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

Изначально Максим собеседовался надолжность CTO, нонаодном изэтапов интервью сучредителями ему предложили еще исменить нынешнего CEO. Отсутствие подобного опыта никого несмутило, ис2013 года Максим стал совмещать сразу две должности. Так онполучил первый опыт именно как менеджер. Пришлось освоиться сKPI, представлением своей компании ипродукта, практикой продаж иразвить способность видеть бизнес-составляющую. Этот опыт очень пригодился позднее.

Проект был чертовски интересным истехнической точки зрения. Посути, это был сбор информации изоткрытых источников (соцсети, объявления), очистка этой информации ипостроение объединенных профилей интернет-пользователей. Информация использовалась для просчета рисков ипрогнозов для МОФ, страховых, банков (для выдачи кредитов, антифрода, форензик расследований ит.д.) Максим сам написал краулер для одной изсоцсетей, нобольше выступал вроли менеджера. Воснове стартапа была работа сbig data имашинным обучением.

В2013 году проект презентовали, активная работа велась до2015, апотом онпостепенно стал номинальным директором ипофакту отдыхал, работая12дня внеделю. Ничего нового уже несоздавали. В2017задумался, что пора двигаться дальше.

Изстартапа вкомпанию-гигант. Опыт работы вAlibaba Group

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

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

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

Вначале работы там Максим много кодил сам наJava иKotlin. Набирал команду, которая создала верхнюю часть бэкенда российского Tmall наAliExpress ифронтенд поиска наJava для московской команды. Работа накитайского гиганта предполагала командировки вштаб-квартире вХанчжоу. Атмосфера похожа наКремниевую долину, нонауровне ощущений было нетак комфортно, как вСША. Максиму нехватило американской мультикультурности иевропейской еды :)

Через год-полтора появились другие команды, иуМаксима стало больше менеджерской работы. Программирование ушло навторой план. Появлялись задачи типа написать ad-hoc запрос наSQL, чтобы проверить гипотезу наработоспособность. Рабочий процесс налажен, стабильная карьера навзлете время наслаждаться успехом. Так решилибы многие, нонеМаксим. Внезапно занесколько дней онподнял планку нановый уровень иизменил всё.

Стать первым EMReddit, нанятым неизШтатов

Здесь тоже все решил нетворкинг ирекомендации. Летом 2020 года Reddit ещё неразмещал вакансий, нобывший коллега Максима изGrid Dynamics порекомендовал имего кандидатуру. Интервью состоялось пятого июня, ипредложение оказалось настолько интересным, что через 10дней Максим Алексеев стал первым EMReddit, нанятым неизШтатов.

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

Как попасть вReddit

Что учесть врезюме

Обязательно, обязательно создайте профиль наLinkedIn. ВСША это основной инструмент HR. Они могут нечитать резюме, нопрофиль посмотрят точно. Такие компании, как Facebook, Google иReddit, восновном ищут именно черезLinkedInили повнутренней реферальной программе.

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

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

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

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

<рекламная пауза>

Вg-mateмного вакансий с ремоутом: можно работать из России или другой страны мира назарубежную компанию. Например, есть вакансия Software Engineer (Backend) вReddit.

</рекламная пауза>

Нужныли сертификаты

Особой роли наличие сертификатов неиграет. Насобеседовании будут смотреть нареальные знания изадавать вопросы поним. Но, возможно, дипломы отпризнанных центров сертификации (pythoninstitute.org,education.oracle.com) будут небольшим плюсом. Сертификатыcoursera, edx.org, udacity.com врезюме наLinkedInтоже увеличат шансы. Самое важное уних должна быть актуальная дата.

Как работать: удаленка или офис

Сейчас Reddit активно набирает бэкенд-, фронтенд- имобильных разработчиков. В2021 планируется развитие внутреннегоQA, ноэти вакансии появятся нераньше января. Обычно Reddit предлагает два варианта работы. Первый удаленно, как правило поконтракту. Или full-time employee (FTE) полный рабочий день вофисе или удаленно напостоянной основе вШтатах, Канаде, Великобритании, Ирландии. Можно сначала пойти наконтракт, апотом решить, хотители выпереезжать водну изпредложенных стран.

Вэтом году коронавирус внес поправки вэту схему: Reddit объявил переход навечную удаленку, втом числе идля FTE. Новшество поначалу вышло боком для тех, кто решил перебраться изСан-Франциско вменее затратный город или другую страну. Внекоторых компаниях Долины переехавшим сотрудникам понизили зарплату, пересчитав под зарплатные расценки нового города. Тоестьте, кто получал хорошую зарплату померкам Сан-Франциско, после переезда стали получать сопоставимо хорошую зарплату, например, для Остина.

Оценив ситуацию, Reddit ввел свою политику, отказавшись отпринципа per city. Теперь зарплатную сетку самого дорогого города встране (для Америки это Сан-Франциско иНью-Йорк) Reddit расширил навсю территорию США. Сотрудник будет получать доход как вСан-Франциско, работая изМайами или сфермы вТехасе. Аналогично это работает ивдругих странах присутствия Reddit.

Этапы собеседования

ВReddit проходит четыре отборочных этапа:

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

  2. Backend интервью. Здесь проверят базовые знания (алгоритмы, concurrency, базы данных, web, software design). Соотношение вашего опыта ирезультатов. Причем вопросы будут зависеть отдолжности, накоторую претендует кандидат. Кпримеру, для джуниоров имиддлов будет важно, где учился истажировался, пригодятся результаты насайтах, где решают задачи онлайн:HackerRank,Codility. Авот для синьоров будет важно, вкаких проектах принимал участие ивкакой роли.

  3. System design интервью. Наэтом этапе нужно спроектировать систему. Здесь важно уточнять требования, обоснованно объяснять, почему спроектировал именно так, ипоразмышлять натему, что делать дальше: как деплоить, что икак мониторить, ит.д.

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

  5. * Интервью сменеджером проекта итимлидом. Вфинале собеседований проверяются софт скиллы исмотрят, подходитли человек вкоманду. Здесьже учитывается, куда можно поставить кандидата наусловной шкале higher potential lower potential. Насколько активно человек стремится кличному профессиональному росту. Бывали случаи, когда кандидатам отказывали наэтом этапе, поэтому важно подготовиться ксобеседованию пософт скиллам.

Особенности устройства наработу вСША

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

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

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

Рекомендации Максима: что почитать иизучить

  1. Grady Booch.Object-Oriented Analysis and Design with Applications.

  2. Андрей Робачевский.Операционная система UNIX

  3. Сайты поSystem Design:infoq.com,highscalability.com,blog.acolyer.org

  4. Технологии, которые пригодятся влюбойIT компании: Python, SQL, технологии Big Data, Data Lake, Spark Streaming, Apache Flink.

Крутые работодатели интересные задачи. Зовите /human в нашем боте: @g_jobbot.

Подробнее..

Собеседуй дружелюбно, работай на перспективу

21.01.2021 08:19:12 | Автор: admin


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

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

Эпизод 1


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

Эпизод 2


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

Эпизод 3


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

Эпизод 4


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

Эпизод 5


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

Эпизод 6


Кандидат прошел интервью, ему обещали перезвонить через какое-то время и дать обратную связь. Проходит много времени, кандидат понимает, что не прошел отбор и забывает про этот неудачный опыт. Разве это нормально? Мне кажется, нет! Если предыдущие 5 ситуаций могут показаться притянутыми за уши или не очень серьезными, то отсутствие обратной связи действительно неприятный момент. Кандидат запомнит не конкретного человека, который не перезвонил, а компанию, которая оставила его без обратной связи, хотя, на мой взгляд, получить развернутый результат интервью право кандидата. Человек готовился, тратил время и вправе рассчитывать на фидбек. За качественную обратную связь несут ответственность все участники интервью. Причем, технические специалисты играют здесь даже большую роль, чем нанимающий hr, который является в вопросе фидбека скорее посредником.
На мой взгляд, если в случае ответа пусть даже отрицательного дать человеку развернутый результат оценки собеседования и указать пункты, которые стоит подтянуть, то с большой долей вероятности человек будет благодарен. А благодарный кандидат уже неплохо.

image


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

Эпизод 7


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

Перевод 10 способов замотивировать команду после провального проекта

22.01.2021 18:12:57 | Автор: admin

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

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

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

Позвольте нам вдохновить вас, как лидера. Здесь вы найдете советы для мотивации и поднятия настроения вашей команды.

Смотрите на картину шире

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

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

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

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

Поддержите членов команды

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

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

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

Не акцентируйте внимание команды на недостатках

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

Уважение и поддержка это улица с двусторонним движением.

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

Будьте готовы к неудаче

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

Обновите рабочее место

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

Сделайте работников счастливее

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

Плохое отношение и неудовлетворенность рабочим место заразительны.

Несчастный сотрудник может распространять негатив. Нужно следить за расстроенными сотрудниками. Разногласия могут возникать и между членами команды, и, возможно, именно тимлиду придется делать первый шаг в разрешении ситуации (http://personeltest.ru/aways/blog.ganttpro.com/en/resolve-differences-in-multinational-company/).

Поощряйте саморазвитие

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

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

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

Бросьте микроменеджмент

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

Планируйте

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

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

Поощряйте малые этапы

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

Невозможно дойти от нуля до сотни за один шаг.

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

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


Перевод статьи подготовлен в преддверии старта курса "Team Lead 2.0".

Узнать подробнее о курсе.


ЗАБРАТЬ СКИДКУ

Подробнее..

Разработчикам в продуктах делать нечего и до 30 лет надо фигачить

24.01.2021 16:23:06 | Автор: admin

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

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

Про возраст

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

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

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

Про опыт

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

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

Ну и всё это на фоне роста основных скиллов.

Если говорить конкретнее, то у нас есть заказчики из финтеха, есть просто технологические компании, есть ecommerce с посещалкой в несколько миллионов. Сомнительных проектов у нас просто нет, мы не беремся за сайты Свидетелей Иеговы, как тутписали в комментах:)

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

Михаил, QA-специалист Holyweb

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

Про стабильность

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

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

Понятно, что работу ты найдешь, и даже, возможно, с запросами я сеньор, 2 года опыта, дайте 250К и личный вертолет. Хотя эйчарам лучше бы насторожиться.

Поэтому аутстафф-компания (по сути сервисная) от такого защищает. Отвалился один проект перешли в другой.

Даниил, React-разработчик Holyweb

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

Про деньги

Ага, вы продаете джунов как мидлов, платите им 30К, остальное в карман! примерно так часто пишут про аутстаффинг.

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

К слову, в одном из предыдущих материалов мы рассказывали, как клиенту работать с таким форматом и разбирали распространенные кейсы.

Про комфорт разработчика

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

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

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

Геннадий, PHP / Node.js разработчик Holyweb

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

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

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

Итого за 2,5 года не было таких случаев, когда бы разработчик хлопал дверью и уходил, потому что ему было некомфортно работать.

Про нелюбовь к релокейтам

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

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

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

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

Про ООО НДА

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

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

Про софт скиллы

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

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

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

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

Про то, как мы собеседуем клиентов

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

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

Более того, эти требования к клиенту могут меняться в зависимости от потребностей команды. Например, у нас был случай, когда разработчику Vue.js накидывали задачи по верстке. Это, конечно, было не тем, что он хотел делать и он нам об этом рассказал. В итоге мы нашли компромисс с заказчиком и разработчик стал получать задачи по Vue.

Петр, React-разработчик Holyweb

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

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


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

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

Дэннис, React-разработчик Holyweb

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

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

Итого, что дает программисту работа аутстаффером:

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

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

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

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

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

  6. Отношение к аутстафферу в команде проекта ровно то же, что и к своим разработчикам это просто выяснено на нашем опыте.

Понимаем, что у вас все равно остались вопросы так что пишите в комментариях или мне в Telegram.

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru