Расписание весеннего Codefest 2012

Задался целью запланировать расписание докладов на Codefest, на которые хочу сходить. 

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

Скачать файл Excel. Пользуйтесь на здоровье! 

Вы стоите ровно столько, сколько зарабатываете

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

Дело в том, что «стоимость» специалиста зависит не только непосредственно от объёма и полезности работы, которую он делает, но и от ряда дополнительных факторов. О них эта статья.

До свидания, Семён (сказка)

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

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

Поток: часть вторая

В дополнение к статье про поток выкладываю видео и слайды выступления на эту тему на одной из встреч Барнаульского PM-Community. В программе:

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

Как поймать «поток», и как сделать так, чтобы он не сорвался

Вступление

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

Первый раз я увидел этот термин на страницах великолепной книги Тома Демарко и Тимоти Листера «Человеческий фактор. Успешные проекты и команды», известной также как Peopleware. Через некоторое время в России вышла книга  «Поток - психология оптимального переживания» автора и основателя этой теории - Михая Чиксентмихайи, которую тоже настоятельно рекомендую.

Итак, сначала теория.

Три шага команды к совершенному коду (+ видео на эту тему)

Преамбула

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

И вот, вы, принимая пост, знакомитесь с командой: вроде бы есть потенциально сильные разработчики с опытом, есть несколько подающих надежды юниоров. Но что-то сразу бросается в глаза. И чем дольше вы вглядываетесь в эти занятые работой умные лица, тем более понимаете, что перед вами не команда, а «группа разработчиков». А то, что они пишут… Вы и не думали, что программисты могут так писать код. Вы смотрите на пластилиновую архитектуру, на классы в 6000 строк кода, на методы, занимающие десять страниц машинописного текста, на кейсы, ветвящиеся как головы Лернейской гидры. И у вас появляется невольный вопрос: а можно ли что-то с такой командой сделать вообще?

И мой ответ — можно. И нужно!

О «достаточно хорошем» ПО

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

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

И, конечно же, я сразу же вспомнил концепцию о достаточно хорошем (good enough) ПО. Итак, вот её основной постулат: мы не стремимся сделать идеально, мы не пишем как попало, мы делаем достаточно хороший продукт.

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

Управление проектами – управление людьми

Первая из статей, опубликованных на Хабре. Статья была написана в далёком 2009 году. Актуально, хотя материал и кажется слегка наивным...


Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления

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

May the Force be with you

Друзья!

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

Если у вас появилось желание связаться со мной, мне можно написать письмо.