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

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



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

Product Manager очень часто выступает первым представителем продукта или сервиса для внешнего мира. Для этого успешному PM требуется опыт, энтузиазм и, конечно, профессиональные управленческие навыки, коммуникативные и другие способности. Набор этих качеств помогает специалисту грамотно представить продукт и вывести его на рынок.

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

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

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

Он собрал совещание, но на нём молчал. И все молчали. Точнее, докладывали статусы и поднимали проблемы. Результат совещания — он написал ещё одно длинное письмо с требованиями и фиксацией статусов с косяками.

Задержки продолжили копиться.

Всегда ли просто определить приоритеты в задачах крупного проекта? А если в приоритете находятся пять срочных задач? Десять?

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

 
Буквально 1,5 месяца назад я писал о возможности установки Kali Linux в Windows окружении используя подсистему WSL. Сейчас появилась возможность установки и запуска Kali Linux из магазина приложений Windows. Это похоже на первоапрельскую шутку, но это действительно так.

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

Интересное наблюдение: мы проводим семинары для проектных менеджеров внутри компании и периодически приглашаем туда ключевых технических специалистов — архитекторов, проектировщиков, тим-лидов. Сначала они довольно неохотно приходят, сидят где-то час и внезапно начинают записывать и задавать вопросы. В конце дня может прозвучать что-нибудь вроде: «А я думал, вы бездельники и упыри, а оказывается, у вас тяжёлая и ответственная работа». Такое обучение сильно помогает участникам команды лучше понимать друг друга.

Более 10 лет в разных должностях я занимаюсь проектным управлением. Поработал в четырёх крупных интеграторах и сейчас возглавляю департамент из 100 человек. За время работы какими только проектами не приходилось управлять: внедряли SAP, автоматизировали деятельность предприятий, разрабатывали ИСы для госзаказчиков, проектировали и строили уникальные ЦОДы, делали военные ОКРы, проводили сложные миграции ИС… — даже строили под ключ электростанции в Белоруссии и угольные котельные в п. Черском (2000 км от Якутска). Основной сложностью тогда оказалась доставка оборудования и материалов — река была проходима только 5 месяцев в году. Вылез за дедлайн или просто поймал холодный год — потерял 7 месяцев. Либо дорогущий вертолёт. Все проекты разные, и каждый по-своему уникален.

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

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



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

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

«Лучший способ писать — это переписывать»
— Пол Грэм, «The Age of the Essay»

Первую подборку на русском всех статей Пола Грэма (а их 176) меня вдохновили сделать ребята из tceh.com (60 переводов).
Вторую — Edison Software (125 переводов).
Третью — Филтех-акселератор (134 перевода и еще несколько в процессе).
На четвертую… уже закончатся эссе Грэма, буду переводить его Twitter (там, кстати, много полезного).

Недавно я подключился к проекту, цель которого содействовать «филантропическим стартапам» (это такие, которые «за добро во всем мире», типа GNU/Linux, Wikipedia и WebArchive). Я вношу свои 5 копеек подборкой самых полезных концептуальных/теоретических материалов про стартапы и стартаперское (хакерское) мировоззрение.

А для тех, у кого все же стартап, а не ICO:

До 16 января 2018 идет прием заявок, предакселератор PhilTech.
С 5 по 23 февраля будет акселерация «по-полной».
С 19 по 25 мая — финальный интенсив в Москве.

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

Кто такой Пол Грэм?
Если вы хоть как-то связаны со стартапами у вас возник такой вопрос, то вам обязательно под кат.

Подборка из серии «добавить в избранное и читать по одному эссе в день».
(хватит на полгода, кстати)

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

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

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

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

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

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

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


Конструирование идей как инновационный магический кристалл

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

Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава QA в Badoo. Сегодня расскажу, как workflow влияет на декомпозицию, насколько отличаются тестирование и выкладка задач, которые появляются в результате декомпозиции, и каких правил стоит придерживаться, чтобы процесс разработки проходил гладко для всех участников.

Помимо извечной проблемы отцов и детей, на мой взгляд, существует ещё одна проблема — подчиненных и руководителей. Именно об этой проблеме я и хотел бы поговорить в своей статье. Точнее, о таком частном случае, как взаимоотношения подчиненных и руководителей при разработке программного обеспечения, конструкторской и технологической документации. Руководители зачастую считают подчиненных безответственными разгильдяями, а подчиненные руководителей — некомпетентными пастухами, которым надо пасти стада, а не командовать подразделением разработчиков. Часто ситуация усугубляется непониманием, т.к. руководитель не разбирается в разработке, а подчиненный плохо понимает административные нюансы. Эта статья призвана помочь плохим руководителям стать хорошими руководителями. Вы, конечно, скажете: «Эй, полегче, какие ещё плохие руководители?». И будете, наверное, правы, я сильно сгущаю краски. Не очень-то и плохие. Обычные руководители, каких сотни и тысячи. Но чтобы качественно выстроить процесс разработки, нужны лучшие специалисты — и исполнители, и руководители. Поэтому руководителей я делю на хороших и не хороших. Без полутонов. Как и разработчиков, кстати, об этом сказано в последнем совете. Как понять, хороший Вы руководитель, или плохой? Почитайте нижеследующие правила. Если какие-то из них кажутся Вам чушью и потаканием бездельникам — значит статья написана для Вас.

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

Не так давно я прочёл книгу «Пиши, сокращай» (авторы — Максим Ильяхов и Люда Сарычева) — современные популяризаторы инфостиля. Крутые чуваки, и книга тоже крутая.

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

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

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

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

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

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

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

На первый взгляд, это хорошая идея. Учитывая практическую вездесущность интернета и электронной почты в сочетании с низкой стоимостью отправки этих писем, возможность понять суть дела «изнутри», которую ваша фирма может получить от клиентов, — что может не нравиться в этой практике?

Обратная связь «магазин/наём -> оценка -> вознаграждение» стала просто неотъемлемой частью некоторых систем. Многие интерактивные торговые площадки включают эти операции обратной связи в рейтинги, которые затем становятся оценкой, влияющей на перспективы оцениваемой персоны.

И вот здесь-то и начинаются проблемы.

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

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

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

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

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

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

Выглядит он так:



А звучит так:

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