Сергей Соловьев о применении веб-технологий с пользой для бизнеса
Сегодня мое внимание обратили на очередной инструмент, который был создан для управления проектами. Я начал смотреть видео-презентацию и быстро заскучал, потому что много раз слышал все идеи и проблемы, возникающие при внедрении подобных инструментов. Тем не менее, я досмотрел 45-минутную презентацию до конца. Вам интересно, почему?
По роду своей деятельности я пользуюсь большим количеством онлайн-сервисов. Чуть ли не в каждой популярной социальной сети у меня есть аккаунт. Наконец, я регулярно наблюдаю за тем, что появляется на рынке, и в каком направлении развиваются лидеры. И чем дальше, тем отчетливее становится заметно, что в Интернете очень активно развивается информационный хаос.
На сегодняшний день у нас есть не только сервисы для создания контента, но и сервисы для его распространения. Что меня озадачивает, так это то, что популярность последних растет гораздо быстрее, чем популярность первых. Наверное, не очень многие задумываются, но если посмотреть на все происходящее “сверху”, то скорее всего, окажется, что объем информации продублированного контента давно превысил объем информации контента оригинального.
Веб-технологии могут помочь бизнесу не только созданием новых инструментов, но еще и оптимизацией процессов обработки информации. Простейший пример — экономия времени для обработки входящих сообщений.
Да, действительно: работа с электронной почтой сейчас довольно удобна. Но информация, которую потребляет обычный сотрудник, сейчас поступает к нему из очень многих источников: это не только Email, но еще и Твиттер, социальные сети, RSS-каналы и т.п. И этих источников становится все больше. Их становится настолько много, что они медленно, но верно начинают кушать лишнее время.
Раньше люди читали газеты по утрам. Они выбирали их сами и успевали осилить как минимум половину за завтраком. Я газеты никогда не читал, потому что, меня не устраивали возможности таргетинга. Интернет позволяет выбирать для себя контент очень точно, но объем этого контента начинает пугать.
На сегодняшний день я читаю:
Я читаю за завтраком, в метро по пути на работу и вечером домой, а также в обеденный перерыв. Во время рабочего дня не читаю, но это самодисциплина, а вовсе не отсутствие искушения.
И должен сказать, что во время чтения постоянно отмечаю статьи и сообщения, как «прочитать попозднее». Это попозднее наступает довольно редко, поэтому очередь таких сообщений сокращается медленнее, чем мне хотелось бы. И кроме того, благодаря невероятному разнообразию Интернета я довольно часто забываю, где и что я пометил, как полезное.
Сейчас на подходе — Google Wave. У него есть свои проблемы с навигацией и системой уведомлений о новых сообщениях. Но легкость, с которой там можно создавать новый контент, настораживает: информации станет еще больше! И техническая платформа этого сервиса (совершенно новый протокол, не совместимый пока ни с чем другим) никак не помогает справиться с переизбытком байтов в моем “почтовом ящике”.
Очень давно и очень сильно хочу, чтобы появилась платформа, которая позволит собрать воедино весь этот зоопарк. Ведь если подумать, разного рода сообщения принципиально ничем не отличаются. Почтовые клиенты уже давно умеют показывать RSS. Остается не так много — позволить подключать сервисы произвольно и работать с контентом в одном окне: просматривать, классифицировать, комментировать, делиться.
Те, кто интересуется тайм-менеджментом и эффективностью, меня поймут. Только представьте, насколько проще станет:
Убежден, что такой инструмент совсем скоро появится. Давайте хотеть вместе! Поддержка сообщества - мощнейшая мотивация для разработчиков!
Большие надежды возлагаю на Raindrop от Mozilla — ребята думают очень похожим образом и движутся совершенно в этом направлении. Хочется верить, что релиз не принесет столько разочарований, сколько принес Google Wave.
Давайте, ребята — сделайте всем счастье! :)
Если Вы работали с людьми, то, вероятно, знаете, что все они очень разные. Одни много знают, другие много умеют, третьи много понимают. Кстати, все это - отдельные навыки. И навыки эти не должны цениться одинаково. По крайней мере, не везде. Об этом сегодня я говорим - что важнее для менеджера проекта: знание и опыт или обучаемость?
При подборе кандидата всегда возникают дилемма. Кто будет более полезен:
Моя практика показывает, что последний вариант очень часто оказывается наиболее эффективным. Обучаемость вообще качество очень полезное в любой сфере, а в сфере управления проектами веб-разработки - вдвойне полезное.
Все-таки у области веб-разработки есть своя выраженная специфика. Достаточно посмотреть на примеры того, что новому человеку необходимо освоить:
Самое интересное в этом вопросе - тот факт, что даже если кандидат обладает необходимым опытом работы в вебе, но не способен быстро и хватко усваивать новую информацию, то все от этого только проиграют. И он сам, и команда, с которой он будет работать, будут испытывать дискомфорт, будут допускать слишком много ошибок и будут больше уставать и меньше производить. Кому это интересно?
Надеюсь, в важности обучаемости я Вас убедил. Теперь немного о том, как прощупать кандидата.
Конечно можно просто спросить в лоб “Расскажите о своем опыте изучения Photoshop”. Но это, к сожалению, достаточно примитивно и, что еще важнее, сразу раскрывает цель вопроса. Умный человек ответит Вам то, что ожидается от успешного кандидата, а вовсе не то, что было на самом деле. А Вы (тоже умный человек) сразу об этом догадаетесь и почти не получите новой информации.
Мой опыт показывает, что собеседование становится интереснее и увлекательнее для всех, если вопросы задаются, так сказать, “по касательной”.
Вопрос: Необходимо интегрировать веб-сайт с ERP системой. Ранее этого в компании не делалось, поэтому требуется изучить стандартные интерфейсы с обеих сторон и найти точки соприкосновения. Как будете решать проблему?
Подтекст: Опытный менеджер проекта знает, что понимание принципиального устройства системы именно для менеджера - довольно важно. Управлять процессом интеграции вслепую - безнадежное дело. Однако человек, который любит учиться, ответит “буду разбираться” с энтузиазмом, а человек, предпочитающий проторенные пути, скажет об усложнении проекта и необходимости привлечения аналитика.
Вопрос: У нас используется своя CMS. Как быстро сможете освоить?
Подтекст: Большинство CMS похожи, потому что решают одни и те же задачи. Поэтому если при ответе человек угадает средний срок освоения (основные функции постигаются примерно за 2 месяца в рабочем режиме), это будет означать, что уже есть опыт, причем адекватный. Если ответит, что заметно больше, значит плохо представляет суть и перестраховывается. Если ответит слишком оптимистично, то хочет хорошее впечатление произвести, не особенно задумываясь. Такого лучше продавцом сделать, чем менеджером проекта.
Вопрос: Проводили ли Вы обучающие семинары для команды Заказчика или коллег? Каковы основные задачи семинаров?
Подтекст: Снова ищем людей, которые станут отвечать с энтузиазмом. Если кандидат говорит, что семинары - это потеря времени, значит он не ценит новые знания. Это ему в управлении проектами никак не поможет.
Вопрос: Имеете ли представление о рестроспективном анализе проектов, понятии извлеченных уроков? В чем их задача?
Подтекст: Человек, который любит узнавать новое, очень часто стремится придать новым знаниям практическую направленность. Такой человек, даже если не знает терминологии, сможет догадаться, что имеется в виду и ответит на вопрос правильно. А терминологию он выучит, не сомневайтесь. Он даже использует ее на собеседовании у Вашего конкурента через неделю, если Вы не возьмете его себе.
Гораздо больше выигрывают те работодатели, которые ищут проектных менеджеров, обладающих именно менеджерскими навыками, а не прикладными знаниями. Обучаемость среди этих навыков занимает далеко не последнее место.
Все рассуждения и выводы, разумеется, основаны на личном опыте. Верю, что он у меня репрезентативный. Если Ваш опыт говорит иное, поделитесь в комментариях - обсудим!
В предыдуших сериях:
Собеседование проектного менеджера - Часть 1 (конвертируем информацию в задачи)
Предолжение серии:
Собеседование проектного менеджера - Часть 3 (предлагаем, а не спрашиваем)
Двигателем любого проекта всегда был, является и будет являться проектный менеджер. Именно этот человек сначала разберет Вам проект на части, а потом соберет воедино. Именно он скажет, когда и кому из проектной команды надо подключиться. Именно он качественно проведет допрос Клиента, а потом всем расскажет, что узнал и что с этим надо делать.
Вопрос в том, где же найти такое сокровище, а точнее - как правильно распознать его среди многих кандидатов, которые пришли устраиваться к Вам на работу?
Вопрос довольно интересный и даже занимательный. За время своей работы в сфере веба я присутствовал на многих собеседованиях, сам провел не одну подобную встречу и видел, что потом из этого получается. И должен сказать, что в ходе разговора крайне важно задать правильные вопросы. Вот о некоторых из таких вопросов мы и поговорим в нескольких статьях.
Первую статью посвятим ориентированности на результат и отношению к информации.
Основная сложность проекта по разработке веб-системы - вовсе не поиск технического решения и не мотивация команды и даже не презентация дизайна Клиенту. Основная сложность - не утонуть в обилии информации вокруг проекта.
Здесь играют роль два фактора:
Надо ли говорить, кто отвечает за определение единственно верного способа реализации проекта и одинаковое понимание этого способа и причин его выбора всеми участниками?
Достижение этого - трудоемкий процесс, в ходе которого на менеджера сваливается огромное количество идей, требований, ограничений, пожеланий, а затем и запросов на изменения. Единственный путь, позволяющий обеспечить успешное производство и завершение проекта - конвертировать всю получаемую информацию в задачи. Это большой талант менеджера, который невозможно переоценить.
В проектной среде задачи обладают принципиальными преимуществами перед “просто информацией”. Вот простые примеры того, что можно сделать с задачей, и никогда нельзя сделать с обычными комментариями/мнениями/документами:
Самое важное свойство задачи - четкий и конечный жизненный цикл. Благодаря этому, информация не зависает, а сразу отправляется приносить пользу. И что еще важнее - она не накапливается. Она отрабатывает свое и умирает, как и положено. Если она не будет умирать, очень быстро в ней утонут все участники проекта.
Задачей должна являться любая информация по проекту: от исходного брифа до акта приемки. Важно, чтобы менеджер был способен увязать ее в единый поток и четко называть, где стыкуются отдельные течения.
Проверьте отношение кандидата к информации на нескольких стадиях проекта. Спросите, какая связь между бюджетом и планом тестирования. Если кандидат ответит, что именно в бюджете определяется, сколько тестеров должно участвовать в проекте, ставьте ему плюсик.
Если кандидат способен проследить, как видоизменяются и детализируются требования в цепочке “ТЗ - прототип - макет дизайна - постановка задач разработчикам - план тестирования”, ставьте ему два плюсика.
Обратите внимание, какими понятиями оперирует менеджер:
Должно быть не “комментарии клиента с презентации”, а “список доработок макетов дизайна”.
Должно быть не “отложенное требование”, а “задача на пост-проектную стадию” или “потенциальная идея для продавцов”.
Должно быть не “Клиенту не понравился цвет кнопок”, а “у нас запрос на изменение - перекрасить кнопки из синего в красный”.
Любите менеджера, который:
Гоните менеджера, который:
Удачных (и продуктивных) проектов!
Продолжение серии:
Собеседование проектного менеджера - Часть 2 (обучаемость проектного менеджера)
Собеседование проектного менеджера - Часть 3 (предлагаем, а не спрашиваем)
