Previous Entry Share Next Entry
Вывести на чистую воду
obrizan
Об успехе программного проекта можно судить по двум характеристикам: а) качество; б) срок выполнения. Если одна из этих характеристик неудовлетворительна, то возникает несколько интересных вопросов:

1. Насколько добросовестно разработчик выполняет свои обязанности?
2. Насколько разработчик компетентен?

Если у проджект-менеджера нет технического образования, то очень легко можно оказаться в ситуации, когда ты уже как бы и не проджект-менеджер, а вешалка для лапши разработчика.

Предлагаю относительно простой метод получения ответов на эти вопросы: попросите программиста задокументировать текущий технический долг по проекту. Для этого следует выделить один рабочий день. Зачем столько много времени? Столько времени нужно для двух вещей: а) дать понять, что задача серьезная; б) достаточно времени, чтобы еще раз пройтись по всему проекту, и подробно все описать.

В результате может быть несколько ситуаций.

Хороший вариант — это когда разработчик просто фонтанирует идеями, что в этом проекте можно было бы переделать: модель улучшить, отрефакторить, написать тесты. Здесь важно, что разработчик не просто кидается модными словами, а имеет конкретный план, в каких местах и что нужно сделать. Не забываем, что времени было дано не пять минут. С таким разработчиком можно и нужно продолжить диалог на предмет понимания ошибок в проекте, извлечения уроков.

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

Проджект-менеджеры, не стоит благодарности.


  • 1
Об успехе программного проекта можно судить по двум характеристикам: а) качество; б) срок выполнения.

Удовлетворённость заказчика входит в лаконичное "качество"?
Или рота идёт в пешем строю, ей похую - и мне похую точно реализованное (но изначально абсурдное) ТЗ - это "успех"?

1. Насколько добросовестно разработчик выполняет свои обязанности?
2. Насколько разработчик компетентен?


3. Насколько ошибочна была исходная оценка трудоёмкости?
4. Какие подводные камни были выявлены в процессе?

Предлагаю относительно простой метод получения ответов на эти вопросы: попросите программиста задокументировать текущий технический долг по проекту.

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

> Удовлетворённость заказчика входит в лаконичное "качество"?

Пусть входит.

> (А) разработчик ясно понимает, что устранять выявленные проблемы он же сам и будет</q>

Вот это вообще отдельная тема. Но если коротко, то кто заварил, тот и расхлебывает. Иначе контур обучения не будет замкнут.

Edited at 2014-02-13 08:15 pm (UTC)

А я бы завела хорошего тех лида и никаких док писать не надо, особенно зная, как сама не люблю это делать

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

Лучше закладывать качество уже на начальном этапе разработки: использовать юнит-тесты, код ревью, итеративный процесс разработки, с хорошей декомпозицией use-case'ов и приоритизацией их же на основе риска.

Также хорошо иметь ответсвенного QA инженера в команде.

> Если текущий код, даже и говно-код покрывает требования заказчика, то зачем его менять?

За фразу "зачем менять, ведь заказчика все устраивает" у нас в коллективе следует удар кочергой по морде. Команду нужно воспитывать так, чтобы каждый член коллектива слушался коллег, а не заказчика.

Строго к прочтению: "Клиент всегда неправ" http://www.artlebedev.ru/kovodstvo/sections/87/

И еще: "От реакции клиента не зависит зарплата дизайнера. В студии дизайнер может получить премию за отличную работу, даже если клиент ее не принял. Потому что важно, чтобы не клиент воспитывал в дизайнере чувство прекрасного, а арт-директор."
http://tema.livejournal.com/1235537.html

Перефразирую

Да ты прав, заказчик всегда неправ.
Но я перефразирую, чтобы лучше донести мысль.
Я считаю, что требования должны быть из вне, даже и со стороны коллектива. Требования к функционированию, что ли.

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

Конечно, могут быть требования от коллектива, типа должно быть очень flexible и high extensibility. Мое личное мнение, что лучше сначала набить достаточно шишек, а потом думать о обобщенном решении. KISS. Сложность, и так, прийдет сама.

куда важней иметь адекватного проджект-манагера) вот кого действительно тяжело найти)

  • 1
?

Log in

No account? Create an account