Ссылка на видео отсутствует или повреждена.

Вход Или регистрация

Войти с помощью::

Регистрация или вход

Обратите внимание, все поля являются обязательными для заполнения.
Войти с помощью::

Восстановление пароля или регистрация

 

 

Александр Горелик:

«Разработка должна быть рентабельной и приносить деньги. Команда разработки не должна делать ничего, что не дает ощутимого эффекта. Исключение – только для стратегических задач»

 

Сегодня на Zillion Александр Горелик из Travelab и Clickavia дает 8 правил для найма разработчиков, рассказывает про модель мотивации, нюансы работы CTO, задачи продакта и фаундера. Заодно у нас тут неожиданная история. Must read.

Интервью:    Анастасия Подберезкина

 

 

Александр Горелик

VP Product / CTO в Travelab и Clickavia. Участник консалтинг-проекта Fckn.Care.

 

Саша, у тебя довольно редкая специализация – как это получилось?

Александр Горелик: Я с шестого класса увлекался разработкой, и к 11-му классу у нас с другом, Ильей Батием, было уже достаточно умений, чтобы делать серьезные вещи. В 2003-м мы решили создать что-то типа Яндекс.Маркета, только удобнее и масштабнее. Отличалась бизнес-модель – у нас была единая корзина, планировали все процессить через себя. За четыре месяца мы сделали портал с поиском товаров и услуг, службой знакомств, почтой, плавающими окнами и возможностью менять интерфейс. Мы хотели создать платформу, объединяющую магазины, бренды, производителей, поставщиков и пользователей, которые ищут товары: охватить все фазы покупки, собрать всех участников процесса в одном месте, дать инструменты под их задачи и возможность взаимодействовать.

В какой-то момент люди даже начали заходить. Мы увидели, что получился классный продукт и теперь надо делать бизнес. Но тогда мы понимали только про программирование, а про бизнес не понимали. И в 2003 году инвестиционной инфраструктуры в России еще не было. Мы начали просто ходить по бизнесменам: два 17-летних парня рассказывали про какие-то там интернеты, логистические площадки, платформу с API для разработчиков. Нас спрашивали, сколько мы хотим. Финансовые модели мы еще не умели строить, поэтому говорили: «Миллион долларов». Денег мы не увидели.

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

Портал назывался Zillion.ru. Несколько месяцев назад я понял, что пора списаться с Дмитрием Грином – решил, что на данный момент этот домен ему нужнее.

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

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

На ранних порах я уже стал разработчиком Senior-уровня, пробовал себя в маркетинге и получил опыт продакта. Это позволило приобрести знания и навыки, которые превратились в сдвоенную специализацию – Product Manager CTO.

 

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

Александр Горелик: Да, совмещение функций CTO и продакта – нетипичная история, но дает возможность увидеть каждую специальность с позиции другой, ну и для компании экономия. Сейчас я VP Product / CTO в Travelab и Clickavia. У нас есть команда разработки, проджект-менеджер, маркетинг, биздев и финансы.

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

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

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

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

 

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

Александр Горелик: А у фаундера вообще печальная жизнь. Если продакта в команде нет, основатель берет на себя все его функции. Потому что никто, кроме основателя, продукт не потянет. Но тут снова возвращаемся к тому, чем на самом деле должен заниматься фаундер.

CTO многие путают с проджект-менеджером. Говорят: «Вот наш CTO». Смотришь, а он в Jirтаски переставляет, и в команде вакханалия. Изначально CTO – это разработчик, по-хорошему фуллстэк. Ну если только он не строит технологию без фронтовой части. Да и то, надо знать все, потому что технологии развиваются быстро, много интересных веяний, и последние по времени фронтэнд-фреймворки – это новый виток, они меняют весь подход к работе. Я вообще считаю, что не должно быть фронтэнд- и бэкэнд-разработчиков, все должны быть фуллстэк. И веб-дизайнер сам по себе не особо нужен на сегодняшний день – он должен быть больше специалистом по UIX.

 

Судя по тому, что ты сказал, продакт – еще и внутренний евангелист.

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

 

Фаундер смирился с тем, что его основная задача – привлечение денег, и теперь ему нужно найти продакта. Как оценить компетентность?

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

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

 

Ок, продакт вот для чего. Но тут у фаундера возникает вопрос: если не он сам занимается продуктом, не деформируется ли идея?

Александр Горелик: А чаще всего она и должна деформироваться. Бывает, что опытные люди давно работают на рынке, увидели проблему и точно поняли, какой продукт надо сделать. Но чаще всего идея 10 раз пивотится, потому что меняется понимание продукта. Например, быстро собрали фидбэк и поняли, что рынку нужно не совсем то. А может и сам рынок поменяться.

 

Что сейчас «продукт» в Интернете?

Александр Горелик: Тут несколько аспектов.

1. Продукт – это ценность. Без Additional Value он не выживает. А ценность каждого продукта в чем-то своем.

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

3. Продукт – это потребность. Нужно либо удовлетворить существующую потребность, либо создать новую. Продукты в вакууме обычно заканчивают печально. Вообще бизнес-модель может быть совершенно неочевидной. Есть классная бизнес-модель Book-Driven Development: вы создаете бесплатную технологию, но к ней нет никакой документации, и чтобы ее понять, нужно купить книжку от авторов технологии. И это работает.

4. Продукт не ограничивается тем, что пользователь зашел на сайт, нажал кнопку «Купить» и что-то получил. Продукт – это совокупность пользовательского опыта. Причем с того момента, когда ты от кого-то об этом услышал. Когда и что говорят о продукте – его составляющие. Это полный цикл: как ты с ним взаимодействуешь, в какие моменты о нем вспоминаешь и т. п.

5. Продукт – это не что-то забетонированное, а живая среда.

 

 

Тем важнее, кто и как делает продукт. Как CTO ты нанимаешь разработчиков, и на это как-то влияет компетенция VP Product, который, по идее, должен понимать и то, как видение реализуется в коде. Есть правила, которыми руководствуешься?

Александр Горелик: 1. Я из 100 кандидатов позову пообщаться двух, а статистика выбора еще хуже. Даже через такой фильтр проскакивают неподходящие люди, и через два месяца работы ты можешь понять, что это не то. Поэтому испытательный срок – не менее трех месяцев.

2. Существует такая проблема: человек проходит все тесты, потому что умеет тесты проходить. Поэтому на техническом собеседовании я задаю хитрые вопросы, на которые можно ответить «да» или «нет» и обосновать. «У тебя был опыт вот с этим?» – «Да, был». – «Тогда такой вопрос. Ответь "да" или "нет" и скажи, почему». И ты сразу поймешь: книжку почитал, что-то потыкал-посмотрел или был опыт применения. Надо спрашивать о том, с чем разработчик, который тебя устроит, точно должен был столкнуться, обматериться и найти решение.

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

4. Если в команде уже шесть человек, а сроки вы все равно срываете, задачи выполняете подолгу, везде вылезают ошибки и каждый релиз что-то ломает, лучше остановиться с набором кадров, это только усугубит проблемы. Сначала надо выявить и устранить первопричины проблем, а они часто находятся вне команды. Например, разработчики демотивированы количеством «критически важных» задач, которые ежедневно сыплются на них из разных источников. Или задачи ставят исходя из горизонта планирования в 1–2 недели, поэтому у команды нет представления, куда вообще все движется, а каждый шаг заставляет что-то перестраивать в системе, хотя многое можно было предусмотреть. Решение каждой проблемы чаще всего на поверхности.

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

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

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

8. Очень важно изначально описать кандидату, с чем придется сталкиваться и какие задачи решать. Не надо давать иллюзий и что-то утаивать. Здесь, как и везде, работает подход ‘Under Promise and Over Deliver’, «обещай меньше – делай больше». Сильную, замотивированную команду разработчиков можно выстроить только через осведомленность и прозрачность.

 

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

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

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

Иногда срабатывает такое решение – повесить перед глазами разработчиков монитор с графиками: сколько живых денег начинает приносить реализованная фича и сколько денег компания теряет из-за серьезной ошибки. Это резко делает людей ответственнее.

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

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

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

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

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

 

Давай еще про геймификацию поговорим. «Практикуем Scrum. Собираемся на стендапы и стоя отвечаем на три вопроса»: как думаешь, существует конфликт менталитета и игровых подходов к разработке?

Александр Горелик: Мы стендапы сидя проводим. Для опытной команды эти нюансы уже не так важны, потому что все понимают цель – сфокусироваться и рассказать друг другу, что сделано вчера, чем будем заниматься сегодня и какие проблемы есть. Игровые подходы работают, но это зависит от того, какая команда собралась. Agile-методологии дают каркас работы, который позволяет быстро понять суть проблемы и избежать бюрократии, характерной для энтерпрайза.

Неопытной команде нужен просто внутренний договор – применять Agile так, как написано. Почему существует консалтинг: приходит человек и полгода внедряет в компании методологию? Невозможно корректно работать по методологии сразу. Есть японский принцип сюхари. Сначала ты все принимаешь за чистую монету: написано, что нужно делать 5 приседаний, 5 подпрыгиваний и 5 наклонов, – просто делаешь, чтобы записалось на подкорку. И только через время, когда все на автомате и появляется мастерство, от правил можно отступать.

Когда методологии не приживаются? Только начали работать по Agile и Scrum, и уже начинается: «Давайте вот это делать не будем. Стендапы эти ежедневные, кому они нужны». А потом кто-то на вопрос «Что ты сделал вчера?» отвечает: «Ну посмотрите в Jirа, что сделал».

 

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

Александр Горелик: Это зависит. Если ты выкатил кнопку, то по скачку конверсии или A/B-тестированию. Изначально надо определить критерии успеха для фичи – в идеале один, максимум два. Например, у Google есть фреймворк для выявления таких критериев – Heart Framework. Можно выбрать технические метрики и, анализируя их, видеть, как только что сделанное приносит деньги или дает рост по стратегическим метрикам.

Моя позиция – разработка должна быть рентабельной и приносить деньги. Команда разработки не должна делать ничего, что не дает ощутимого эффекта. Исключение – только для стратегических задач. Понять, что задача стратегическая, легко: «Если не сделать этого сейчас, то через год компании не будет».

 

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

Александр Горелик: На мой взгляд, будут жечь биоинженерия и биоинформатика. Там и Aging, и новые материалы, и еще тонны всего. Но эти области требуют больших вложений и особой квалификации, там работа с Big Data и специфическими технологиями.

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

Я думаю о своем будущем в направлении энергетики, биоинформатики, биоинженерии и синергии этих направлений.

 

Что сейчас, на твой взгляд, важно учесть, работая над IT-продуктом?

Александр Горелик: Я вижу такие важные аспекты.

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

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

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

3. Делать не продукт, а платформу для быстрого и гибкого создания продуктов.

4. И строить систему так, чтобы максимально обезопасить будущее стартапа, потому что все работают в поле неизвестности.

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

Есть еще одна важная вещь – в мобайл. Многие делают мобильную версию того, что пользователь видит на десктопе. На мой взгляд, это неправильно, потому что там совершенно другой пользовательский опыт. Хороший подход – понять контекст пользователя, откуда и с какими потребностями он пришел. К примеру, ребята из HotelLook взяли за основу то, что люди выбирают отели по фоткам, и решили, это должно стать главным в приложении. Для мобайла надо не копировать десктопную версию продукта, а показывать то, что ищет пользователь в контексте его ситуации, но в нужной вам формулировке – «взгляни на это вот так». Я редко вижу примеры, когда в мобильной версии полностью меняют поведение. Вот у LinguaLeo приложение дополняет то, что ты делаешь на сайте. В общем, приложение должно удлинять твой продукт.

 

А вот говорят о движении от десктопного к мобильному.

Александр Горелик: Иногда даже говорят про Mobile Only. Да, Mobile First во многом, потому что телефон всегда под рукой. Но в реальности от десктопов никто отказываться не собирается. Если у тебя обычный интернет-магазин без мощного бренда, то ты уже проиграл, стал прослойкой, потому что есть агрегаторы, и именно туда люди будут заходить с телефона.

Фото: Zillion

Теперь вы можете заходить на Zillion по адресам Zillion.ru, Zillion.net и Zillion.academy  

Смотрите на Zillion

Экспресс-курс

Профессия Project Manager. Как стать PM'ом

Видеокурс

Big Data. Как большие данные меняют бизнес и жизнь

 

 

Комментарии 3

Мы тоже ощутили реальную эффективность, когда начали автоматизаровать бизнес.
13 июня 2016 г. в 8:01
0
Ответить
Elena Yureva
Пользователь
У нашей компании пока автоматизация бизнес-процессов только в планах.
14 июня 2016 г. в 11:13
0
Ответить
Антонина Василина
Пользователь
Лично знаком с Александром. Он знает, о чём говорит. Тот самый случай, когда общаешься с экспертом-практиком, который ценит и время и IT-бюджет и не расходует его зря.
11 декабря 2015 г. в 16:19
1
Ответить
Алексей Бобко
Автор

Отправить комментарий на Facebook


Рекомендуем к просмотру
Тренды
Новое на Trendspot. Флэш-фикшн: твиттература, чат-книги, дрибл, драбл, 6 и 9. Создатель Telegram-канала «Кароч.» Дмитрий Соловьев рассказывает о микролитературе и фикшн-форсайте
26 августа 2017 г. 19,045
Тренды
Подписывайтесь на новый блог Trendspot by Zillion
13 августа 2017 г.
19,299
Менеджмент
Владимир Завертайлов: «Мой телефонный номер есть в подписи у всех менеджеров. Клиенты этим пользуются редко, но возможность такая есть»
12 июня 2017 г.
20,315
Управление проектами
Zillion.Quick: «Управление продуктом в Scrum», Роман Пихлер
8 июня 2017 г. 17,778
Управление проектами
Мемесы про пиэмов. Chapter 1: топ-5 Романа Вейнберга
18 мая 2017 г.
18,988
Управление проектами
Правда жизы. Владимир Завертайлов («Сибирикс») про управление проектами (18+)
16 мая 2017 г. 5,349
Управление проектами
Стейкхолдер-менеджмент. Как идентифицировать, анализировать и вовлекать стейкхолдеров в проект
15 мая 2017 г.
6,711
Бизнес и финансы
Артур Шомахов: «Бизнес – это деньги, поэтому день надо начинать с денег. Каждое утро у тебя должно обновляться понимание того, что творится с финансами»
9 сентября 2015 г. 24,017
Управление проектами
Zillion.Quick: «Канбан» Дэвида Андерсона
6 мая 2017 г. 7,869
Управление проектами
Zillion.Quick: «Мифический человеко-месяц» Фредерика Брукса
26 апреля 2017 г. 4,848
Управление проектами
Павел Капусткин: «Смотри, наиболее вредна для пиэма непродуктивная эмоция»
12 апреля 2017 г.
21,252
Управление проектами
Чем занимается Project Manager?
20 марта 2017 г.
24,394
Управление проектами
Zillion.Quick: «Корпорация гениев. Как управлять командой творческих людей», Эд Кэтмелл
9 марта 2017 г.
7,988
Управление проектами
Проектное мышление. Поиск инвестиций: зачем использовать CRM
23 февраля 2017 г. 7,987
Управление проектами
Надпрофессиональные навыки: управление проектами
22 февраля 2017 г. 7,414
Управление проектами
Управление проектами: как организовать путешествие
14 февраля 2017 г.
7,561
Развитие персонала
Zillion.Quick: синопсис + инфографика. «Лидер и племя. 5 уровней корпоративной культуры»
9 февраля 2017 г.
7,290
Образ жизни
Как пробежать свой первый марафон
19 января 2017 г.
10,017
Edutainment
10 самых читаемых материалов года
31 декабря 2015 г. 9,517