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

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

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

Итак, мы приходим на работу и, вуаля, через 40 минут назначено совещание (митинг). Тема «Обсудить решение текущих проблем», продолжительность 1 час, в списке приглашенных 8 человек. 40 минут томительного ожидания и мы на месте — здороваемся с коллегами, настраиваемся на конструктивный лад. Появляется организатор, бодренько стартует и… уже через пять минут мы понимаем, что в очередной раз теряем время. Вроде бы, и обсуждаемые проблемы вполне реальны, и присутствует достаточно людей, но совещание неуклонно превращается в бесцельную дискуссию.

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

Идея, вкратце:

1. Я ставлю расширение. На этом активные действия с моей стороны заканчиваются.
2. При загрузке текста любой веб страницы, расширение случайно отбирает 10% русских слов и подставляет вместо них английские, полученные через Google Translate API.
3. Я свободно читаю текст с подставленными словами (90% слов не меняется).
4. Я читаю десятки статей ежедневно, каждая из которых это небольшой урок подсознательного запоминания иностранных слов.
5. PROFIT

Подозреваю, что работы тут немного. Буду первым благодарным юзером.

PMP традиционно входит в десятку самых востребованных IT сертификаций на западе. Эта мода потихоньку перебирается и в страны СНГ, некоторые компании уже начинают робко писать в вакансиях «PMP credential is a plus». Помимо повышения ценности ПМа на рынке труда, подготовка и сдача PMP сами по себе дают полезные знания и опыт.

Под катом — пошаговая инструкция получения PMP на базе PMBOK4.

В одной из книг ДеМарко была приведена интересная история. Представьте, что к руководителю проекта приходит представитель Всемирно Известной Организации по Измерению Качества и сообщает, что команда проекта попала в Топ 10 всех команд в мире по качеству кодирования.

О чем думает руководитель? Его сердце наполняется теплотой и проскакивают мысли «Вот молоцы! А я всегда подозревал...». После чего, представитель вдруг возвращается и приносит свои извинения — произошла ошибка, проект на самом деле 10й с конца. Настроение руководителя кардинально меняется и он уже вовсю проклинает свою команду.

В чем ошибка руководителя? Он не измеряет качество кода.

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

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

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

Моя версия под катом.

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

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

В IT индустрии все чаще встречаются проекты с распределенными командами. Это удобно — спецификация, код, баги, мануалы легко перемещаются из одного конца планеты в другой за доли секунд. Это выгодно — аутсорсинг проектных процессов, будь то разработка, тестирование или саппорт, в Индии или Китае обойдется в 3–5 раз дешевле аналогичных сервисов в странах Европы или США.

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