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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сейчас в одной переписке возник вопрос по поводу нужно ли описывать систему, делать ТЗ и пр. Это в контексте небольшого сайта, выполняемого парой-тройкой человек. Одним из аргументов против, было то, что это займет лишнее время.
Я же в последнее время склоняюсь к мысли что любую программу нужно проектировать до начала разработки, как раз для экономии времени.

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

Но в случае если над проектом трудятся несколько человек (и, конечно, проект отнюдь не маленький) то тут нужно полное планирование. Нужно записать все состояния системы, переходы между ними, способы взаимодействия с пользователем и т.д. Читать далее »»