Игорь Артамонов

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

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

Есть такое интересное разбивание проекта на этапы, как я называю «по правилу 90%». Я не знаю откуда я его взял, может где-то прочитал, может сам это вывел, может еще что-то, но тем не менее:

1. Команда рано или поздно приходит к моменту когда проект «уже сделан на 90%» — что-то уже запускается (в идеалистичном use case) , есть какая-то система, казалось бы осталось лишь допилить чуть чуть.
2. Но на самом деле это лишь начало. Дальше еще столько же до того момента когда продуктом можно будет реально пользоваться, когда он станет работать у другого человека, перестанет падать в ситуации отличающейся от идеальной и т.д. Вот тут да, снова дошли до стадии «готово на 90%».
3. И это оказывается не все... Теперь нужно допилить чтобы все было «красиво», удобно, чтобы это поддерживалось, запускалось из коробки, были написаны инструкции. И после уже снова «готов на 90%», тут уже и правда почти готово.

Читать далее »»

В предыдущей заметке про психологические роли разработчика я сказал что они явно конфликтуют друг с другом, и я утверждал что это конфликт очень важен. Т.е. я вообще сторонник того что конфликт это нормально, он нужен, если его видеть, правильно понимать и направлять на благо компании и его участников. А если нет конфликта, и два человека полностью согласны во всем друг с другом, имеют один взгляд во всем, то зачем нужен второй человек?
Читать далее »»

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

Он выделил 4 роли: Producer — Administrator — Enterpreneur — Integrator — сокращенно PAEI. Адизес описал все в общем случае, мне же это интересно на примере команды разработки ПО. Только я позволю себе перевести названия ролей не дословно.
Читать далее »»

Вот кстати замечательный доклад по поводу оценки сроков от Максима Дорофеева: Курс естествознания для менеджера проекта, рекомендую потратить время и посмотреть/послушать.

Ну и, бонусом к оценке сроков, идут интересные слайды про «Персики и Лимоны», как отличное дополнение к принципу Питера

Представим себе что вы решили купить себе телефон, для наглядности представим что это iPhone 3Gs.

В сети находите 3 варианта покупки:

• 10 тыс. руб — и как получится, может завтра, а может через месяц, может вообще не доставят, но денег в любом случае не вернут. К тому же на корпусе могут быть какие-то подозрительные царапины и непонятные люди в списке контактов. Или вообще другой телефон привезут, ну и может денег сверху попросят, лишь потому что у них там какие-то непонятные вам «проблемы возникли с товаром».
• 15 тыс. руб — может быть завтра уже доставят, но черт его знает на самом деле, есть некоторая путаница со складами, курьерами, наличием, в общем они обещают на днях позвонить и сказать точнее что как будет, может сразу доставят, может в течении недели, ну или как получится.
• 20 тыс. руб — послезавтра ровно в 14:25 курьер с товаром будет у вас в офисе. точка.

Вы какой выберете? От чего зависит решение?
Если по цене, то третий вариант в 2 раза дороже первого. С другой стороны у него гарантия доставки, или вы готовы сидеть на одном месте и ждать курьера сколько угодно?
А если вы руководитель компании и закупаете их сотрудникам, что вы им скажете? А перед своим руководителем в такой ситуации как обоснуете выбор и отчитаетесь?

На самом деле почти риторические вопросы, просто повод поразмышлять о том как думает заказчик разработки софта. Цена, предсказуемость результата и пр.

PS: а еще можно было бы это разбить на 5 вариантов, чтобы сопоставить с уровнями CMMI

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

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

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

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

Standup'ы одна из основных частей «гибких» методологий, описано практически во всех книжках по гибким методикам, и, я считаю, обязательная вещь для команд от 2 до 15 человек, какую бы методику производства софта они не исповедовали. Наверное, все понимают, что коммуникации при разработке софта очень важны, их всегда мало, так вот стендапы отлично увеличивают объем общения в команде, и вообще приносят очень сильный прирост производительности.
И это, кстати, отлично приживается и без использования прочих методик из этой же серии, вроде парного программирования, карточек с пользовательскими историями, и пр.
Хочу заметить, что я говорю это исходя из собственного опыта, а не прочтения статей и книг.

Под катом более-менее подробной описание сути этого подхода, в вопросах и ответах. Читать далее »»

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