Когда начинать кодировать?

Уже как-то писал, что ТЗ дает возможность дешево "проиграть" проект - без реализации.
Встретилось еще одно подтверждение мысли:

• Статистика говорит о том, что более 50% дефектов вносится в программу до кодирования.
• Статистика говорит о том, что кодирование, как правило, является самым дорогим участком.

Влияет ли отпускная политика на качество разработки ПО?

Влияет ли отпускная политика на качество разработки ПО?

На что тратится наше время :)

Интересное IT-мероприятие от Виктории Придатко

http://hr-maverick.blogspot.com/2010/12/15-it.html

В очень простом и демократичном формате, вечерком, в офисе Циклума рассказали о своей практике два человека.

Один из докладов - о том, как работают с распределенной командой:

• Четкий, фулл-тайм график, синхронизированный со всеми. С 11 до 20.
• Обязательные совещания КАЖДЫЙ _вечер_. [пока еще не встретилось описание успешной ораспределенной команды без них].
• Не нанимают людей с детьми - считают что с работой это не совместимо
• Отдают предпочтение работавшим в оперсорсе, и табу на работу с фрилансерами. Пытаются работать только с лучшими.
• Слабые девелоперы тянут производительность _всей команды_ вниз (?)
• Исповедуют "меритократию" - на тех. уровне должна быть иерархия авторитетов, демократия не работает. Кто-то должен иметь возможность принять окончательное решение.
• Активно используют механизм burn-down диаграмм. Горизонт планирования до месяца, обычно меньше. Попробовали на три - фейл.

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

Второй доклад более прагматичный и механический, про Зарплаты в ИТ, но через призму аутсорса:

• По статистике при переходе подъем ЗП обычно 25%
• У человека прыгающего по компаниям зп растет быстрее, чем у эволюционно растущего на одном месте
• Если использовать бонусы, то не менее половины зп, иначе они не работаю/мотивируют (?)
•  Составляющие пересмотра зп:
   - инфляционная (для $ сейчас 5%)
   - рыночная
• Частота перемотра до мидла - раз в 2-6 месяцев, для мидлов-синьоров - раз в год
• Один из способов обсуждения повышения - спросить у человека как он видит составляющие своей зп, и за что он хочет повышения в данном случае.
• "шантаж уходом" - работает один раз, потом нужно увольнять(если конечно предыдущие пункты исполняются) (хотя на это звучали возражения)
• Безпроцентный кредит - эффективный механизм мотивации. После его выплаты у сотрудника создается иллюзия повышения зп.

UPD
Вот еще одна подборочка - http://sergtk-it.blogspot.com/2010/12/it.html
Интересно, но многие вещи мы восприняли совершенно по разному :-/

UPD2 
Презентации http://hr-maverick.blogspot.com/2010/12/15.html

"...и ждем, что они друг с другом договорятся. Они не договорятся."

Интересное интервью и цитата из него:
 
http://experience.openquality.ru/elena-sagalaeva-interview/

Елена, сможете ли вы рассказать о наиболее значимой ошибке, которую вам доводилось видеть в проектах?
Самые суровые проблемы возникают из-за неверно принятых решений, не из-за того, что программист где-то плюс с минусом перепутал. И из-за попыток решить технические проблемы политическими методами. Или вот, например, ставим работать программистов, которые друг друга не знают. Не назначаем среди них главного и ждем, что они друг с другом договорятся. Они не договорятся. Это классическая запланированная катастрофа, я несколько раз такое наблюдала.

Высоконагруженные системы

Встретилась хорошая подборка статей про высоконагруженные системы -  http://www.insight-it.ru/highload/. Конечно очень обзорно, но есть очень интересные моменты. Рекомендую.

PS
Интересно, а что можно считать критерием сложности проекта? Ведь высокая нагрузка - это только одна сторона медали.

Тонкости внедрения

Интересная статья и замечательнейшая цитата из нее:

Я потратил на этот проект почти год своей жизни. Это много. И обидно.
А тем, кто планирует участвовать в подобных проектах, хочу сказать — ребята, в таких крупных компаниях гораздо важнее не суть дела, а правильная политика и учет клановых сил. Главное знать, кто тут на кого имеет какое влияние и с кем и в какой последовательности надо все согласовывать. А насколько хорошо то, что именно вы предлагаете, значение имеет не очень большое.

Не ново, но так за живое задевает...

Сложности общения

Встретился хороший пост про некоторые аспекты общения. С которыми не раз сам такливался на практике. Цитаты из статьи Владимира Германа “Личная неприязнь”.

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

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

Ошибки и правила оценки программных проектов

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

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

http://www.ozon.ru/context/detail/id/3115179/

Но кому лень искать, покупать или читать - на Хабре встретился кратенький пост, с пересказом - http://habrahabr.ru/blogs/pm/75903/

UPD
Встретилось еще близкое к теме - “Статистические ошибки планирования”. Очень интересное выступление, с примерами, "на пальцах".

Мысли о роли ТЗ в программном проекте

Так, когда-то написал, отходя от проекта, в котором вовлеченности непосредственного заказчика по сути не было

Основная задача ТЗ в программном проекте - не фиксация объема работ, не защита от переработки, не инструмент "заморозки" требований. Нет, это просто возможность заказчику(пусть зачастую и при помощи разработчиков) подумать над тем, что он вообще хочет.

Можно конечно сделать проект "самостоятельно" и сдавать его итеративно, но, как показывает практика, в этом случае думать над ним заказчик начнет как раз в момент сдачи. И запросто окажется, что "когда я говорил мне нужен дом - я имел ввиду вышку аэропорта".

Другими словами ТЗ - это "рыба" проекта, которую можно делать сразу, просто и очень дешево менять. А письменный он должен быть потому, что иначе мозг может и не включиться. П%;:ть, как грится, не мешки ворочать.

PS термин "техническое задание" спорный, но выбран как самый простой, для обобщения

PPS да, agile конечно штука, но не каждый заказчик готов по нему работать

UPD: мысль оказалась далеко не новой - Джоэль о том же пишет.