понедельник, 14 декабря 2015 г.

Оптимальное распределение ресурсов команды по задачам продукта

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

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

На одинаковых требованиях каждой области продукта это отлично работает. Внутри одной области работает еще лучше. Однако если требования различны, то перескакивание с одной области на другую может быть дорогим, ведь опыт и знания не появляются мгновенно. Возникают задержки на "в первый раз вижу", "а я и не знал" и банальное "вспомнить что я тут вообще делал в прошлый раз три года назад". Эти задержки "съедят" нужное им время и потом конечно же исчезнут, а разработчик наладит адекватную скорость работы. По моему опыту, это примерно полгода-год. Но потом с ним снова случается планирование и приходят новые Самые Важные Задачи, происходит новый скачок в соседнюю область и задержки возвращаются. На протяжении в три года или больше этот подход может стать катастрофическим для продукта: каждая его область начинает отставать от ситуации в мире, от конкурентов, от ожиданий клиентов и других факторов меняющегося окружения. Происходит осознанная и неосознанная компенсация скорости работы за счет качества результатов. А компания получает не очень-то веселый изменение: источник доходов был, а потом "сам собой" слился.

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

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

Однако и этот вариант можно назвать неэфективным из-за постоянной поддержки на развитие каждой области: задачи в ней совсем не Самые Важные, однако ими постоянно кто-то занимается. Это широкий простор для амбициозного руководителя: "Я нашел где мы можем здорово сэкономить! Ура мне и премию!" Или для бюрократа "По принятой методологии должен быть список задач и все должны их делать в порядке приоритета! Я наладил такую работу, ура мне и премию!" Эффект от такого изменения заметен сразу: Самые Важные Задачи кто-то сразу начинает делать! Они уже не ждут своей очереди! Они уже в списке "Doing"! Премии получены, все воодушевлены и с уверенностью смотрят в будущее.

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

Вот такой невеселый конец.

четверг, 12 ноября 2015 г.

"It seems that it's a bug in your product"

А есть ли "баги" вообще? Не в каком-то конкретном приложении, а существуют ли они в принципе как самостоятельный отдельный элемент в процессе разработки и сопровождения программ?

понедельник, 17 августа 2015 г.

"An item with the same key has already been added"

Type:       ArgumentException
Message:    An item with the same key has already been added.
Data:       0 entries
Stack trace:
   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   at ...

суббота, 27 июня 2015 г.

Как начать работать и зарабатывать

Фраза, затертая до дыр, но до сих пор не растерявшая своей магии... Например, в разработке программного обеспечения.

воскресенье, 8 марта 2015 г.

Полиморфизм?


Вот в таком классе мне недавно пришлось исправлять ошибку:

public abstract class UpdaterBase {
protected abstract IMyControl CreateMyControl();
protected abstract IMySettingsStore CreateMySettingsStore(IMyControl control);
public void Update(MyTarget target) {
if(target != null && !MySettingsHelper.HasSettings(target)) {
IMyControl control = CreateMyControl();
control.Fields["Priority"].Area = MyArea.ColumnArea;
control.Fields["Subject"].Area = MyArea.DataArea;
control.Fields["AssignedTo.DisplayName"].Area = MyArea.RowArea;
MySettingsHelper.SaveSettings(CreateMySettingsStore(control), target);
}
}
}

На первый взгляд этот код выглядит нормально: базовая логика для использования и перекрывания и все такое про ООП и полиморфизм. И даже наследники есть: