Можно всю эту статью ужать до одной фразы. Manage people, not tasks. Управляйте людьми, а не задачами.

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

Если не согласны с последним, это ваше дело. Потому что на этой идее построена вся современная научная часть управления проектами. Six Sigma, Toyota Production System, TQM — это все результат той же идеи, которая в своем самом жестком варианте звучит так. «Проект — это команда». Особенно читывая, что фактически единственный инструмент и ресурс в информационном бизнесе — это люди.

От «командной работы» до TPS в действительности не так далеко. Сначала появилось управление командной работой, HIM (Human Interactions Management), потом уже возникло управление бизнес-процессами, BPM (Business Process Management). Так что начинать выстраивать Тойоту из своей компании нужно с команды. С людей.

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

Как утверждает Уильям Джойс в книге "Формула устойчивого успеха в бизнесе 4+2", есть 4 фактора успеха бизнеса:

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

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

Для начала в команде выстраивается процесс сотрудничества и переговоров (важные качества: творчество и доверие). Затем каждый участник команды работает с внутренним желанием удерживать формат (ответственность, четкость). А уже только потом форматы процессов формализируются и «зашиваются» в систему, в ПО. Система — «после» человеческого взаимодействия, не «до». Именно об этом говорит Манифест быстрой разработки, Agile Manifesto: «Люди и взаимодействия важнее чем процессы и инструменты».

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

   Этот небольшой пост легко мог бы украсить самый читаемый блог «Учись работать», но…

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

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

Недавно дочитал книгу «Стратегия голубого океана» У. Чан Кима и Рене Моборна. Отдельными моментами напоминает ТРИЗ (Теория Решения Изобретательских Задач) что конечно весьма порадовало. После прочтения сформировался ряд тезисов.

Я думаю некоторые из веб-разработчиков сталкивались с задачей создания сайтов и сервисов под мобильные платформы. И проблема возникает в том момент, когда надо протестировать свое творение. И если найти тот или иной девайс все же не проблема, то протестировать на максимальном количеством устройств достаточно сложно. И тут на помощь приходят ОНИ — эмуляторы. В данном посте я рассмотрю вопросы установки и запуска эмуляторов следующих мобильных устройств, с целью запуска на них нужного сервиса: Win Mobile, iPhone, BlackBerry, Android, Symbian^3.

Скажу сразу — «Америку не открываю», так же как не «изобретаю велосипед». Статья базируется на модели ситуационного лидерства Херси-Бланчарда. Сама модель в значительной степени изменена в применении к управлению именно ИТ-командами в нашей стране и подкреплена практическим опытом управления командами в Майкрософт Рус и в собственном бизнесе.

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

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

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

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

Поискал на Хабре, не нашел рецензии на русское издание знаменитой книги Гая Кавасаки The Art of the Start (2004) (на англоязычную было), поэтому решил «закрыть брешь» и поделиться ее кратким содержанием и своими мыслями.

Итак, в русской версии книга получила название «Стартап. 11 мастер-классов от экс-евангелиста Apple и самого дерзкого капиталиста Кремниевой долины».

Если вы производите прорывной софт для разведения креветок, то эта книга точно для вас.

Завершившийся на прошлых выходных Russian Startup Challenge высветил огромную проблему — непонимание между двумя основными участниками этого рынка, инвесторами и самими стартаперами.

Многие привыкли, не вникая, громко заявлять на каждом углу: «В России нормальных стартапов нет, мы все берем с Запада, и совершенно не в состоянии ничего хорошего придумать». Разумеется, это НЕПРАВДА. Уровень большинства финалистов Challenge ничуть не хуже тех проектов, которые участвуют в известных конкурсах TechCrunch или YCombinator. Однако, например, проект task.ly, который сейчас (вполне заслуженно) входит в шорт-листы нескольких крупных европейских стартап-фондов, вызвал на конкурсе далеко не однозначную реакцию.

О чем это говорит? О том, что инвесторы или эксперты не те? Рунет плохой? Стартапы «неправильные»? Однозначно — нет. Это говорит о некой «системной ошибке» российского рынка стартапов.

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

• CMS общего назначения. Информационные сайты, визитки, блоги…
• Многофункциональные монстры.
• Галереи.
• Социальные сети.
• Форумы.
• Интернет-магазины.

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

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

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

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

Всего 25 вопросов, прибавляйте вашему приложению по баллу за каждое «Да». Если не уверены в ответе, или можете ответить положительно только на одну часть вопроса, смело отвечайте «Нет» и переходите к следующему.

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

Есть модель мира, и есть реальный мир.
Как в физике — есть какое-то явление, а есть его модели.

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

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

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

Вот только отличий от физиков тут три. Первое — это незнание природы работы мозга. И отсюда вытекающая уверенность, что все, что человек видит, думает и знает — и есть истина. То есть человек себя убедил (читай сделал себе модель) в том, что Windows лучше, чем Linux — все, теперь в его модели мира может быть только этот факт. Второе отличие как раз в уточнении модели. Люди не уточняют модели реальности, как правило, более того, мозг специально отсекает факты, противоречащие модели, либо вырабатывает «адаптеры» в виде «логических объяснений», чтобы не нарушить комфорта в восприятии мира — все знают нелюбовь к изменениям, боязнь, что «мир встанет с ног на голову».

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



Структурно хотелось бы рассмотреть все таким образом:

1. Функционал
2. Стратегия + тактика
3. Области применения
4. Примеры
5. Дополнительные материалы

Во время dot com бума мы с друзьями основали стартап, где я был техническим директором. Мы разработали систему управления знаниями. Это была комбинация блогов, wiki, системы управления документами, социальных закладок. Мы начали в 1999, что было несколько рановато для wiki и блогов (Movable Type вышли на рынок в 2001). Социальные закладки, по сути, были точно такими же, как станет впоследствии Delicious. Помимо этих новых и замечательных идей (по крайней мере для 1999 года) у нас было три отличных особенности:

• Всему можно было присвоить метки (tags): навыкам, людям, ссылкам, документам, постам в блогах, страничкам в wiki. Что-то, что теперь называется фолксономия. Метки могли соотноситься с другими метками и формировать онтологии. Метки могли ссылаться на другие документы, посты, людей.
• Всему можно было поставить свою оценку от 1 до 5.
• У нас был умный нечёткий поиск, основанный на метках и оценках. Например, при поиске «люди со знанием Oracle» в выдачу также попадали специалисты по SQL Server'у — например, чтобы укомплектовать команду, если не было свободных гуру Oracle.

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

Ранее я упомянул свою ставку 100 долларов в час. Я получил десятки комментариев с общим смыслом “получать так много нескромно”. И никто не сказал “работать так мало нескромно”. Почему-то считается, что работать надо хотя бы 40 часов в неделю. Общество настроило нас:

• работать надо много
• жизнь должна быть трудной
• времени должно не хватать.

“Welcome to real life. It sucks, but you’ll get used to it”, – говорят в сериале Friends.

Сколько стоит мое время?

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

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

Оно того не стоит

Стоит выяснить цену своего времени, как можно забить на убыточные дела. На прошлой неделе я ходил в театр Станиславского на “Севильского цирюльника” и забыл бутылку вина в камере хранения. Вино стоило 287 рублей, до театра идти 15 минут туда и 15 минут обратно. Получается, что при часовой ставке до 574 рубля дело выгодное, иначе выгоднее не забирать.

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

Вот примеры того, где можно сэкономить: