17 Март 2007

Словарь ненормативной лексики

posted in Инженерия ПО, Юмор |

Нашел в сети интересную статью Игоря Ашманова, относящиеся к управлению проектами: Правила Ашманова. Статья спорная, по тезисам статьи можно и нужно спорить, но больше всего мне понравилась подборка словарей ненормативной лексики в качестве приложений.

Хочу привести некоторые примеры из словаря ненормативной лексики программиста:

  • Ну, не знаю, у меня на машине всё работает.
    Комментарий: это неправда. То есть, конечно, что-то работает — после серии магических пассов, недоступных пользователю и тестировщикам.
    Мои комментарии: Чаще всего проблема либо в том, что разработчик не может охватить проблему целиком, либо ему просто лень в ней разбираться.
  • Да у вас просто «Винды» кривые.
    Комментарий: это не имеет никакого отношения к делу. У большинства пользователей в мире «Винды» — кривые, а прикладные программы все-таки работают.
    Мои комментарии: Это высказывание по своей сути не отличается от предыдущего.
  • Попробуйте перезапуститься. Думаю, всё заработает.
    Комментарий: это маловероятно, хотя возможно. Но программа должна работать и без перезапуска.
    Мои комментарии: м-м-м… Да, наведенная ошибка самая тяжелая для воспроизведения, и не всегда надо ее решать. Главное не выплеснуть ребенка, тьфу, главное не пропустить настоящую проблему.
  • Как дела в проекте? Работа ведется!
    Комментарий: «Работаем» — обычный ответ разработчика на вопросы менеджера. Помогает «отбить» две трети, а то и четыре пятых запросов о ходе проекта. Сам по себе этот ответ — не криминал, и на самом деле в разработке бывают периоды упорной работы «от забора до обеда», когда результатов не видно. Но частое повторение этой формулы подозрительно — она может служить и для сокрытия уже обнаружившихся проблем со сроками и трудоемкостью, которые разработчик надеется решить сам, не доводя до начальства.
    Мои комментарии: Разработчику в голове приходится держать кучу данных: имена переменных, сигнатуры вызовов функций и прочую важную информацию. Может его просто напугали ваши позывы объяснить состояние в понятных вам терминах, например, в процентах выполненной работы? Не все так просто… Надо делать шаги навстречу, причем с двух сторон: обобщение со стороны разработчика и попытка вникнуть во все технические детали с вашей стороны.
  • Я уже неделю ночами работаю, а вы меня укоряете за срыв срока.
    Комментарий: ночная работа — это вовсе не доблесть. Скорее всего, просто у программиста сложился такой режим (что часто бывает), а в сутки всё равно выходит 8-10 рабочих часов. Даже если и была бы переработка, то это недостаток организации работ.
    Мои комментарии: Все практики плохо относятся к систематическим переработкам, которые существенно снижают производительность. А по поводу комментария выше… Нужно четко понимать и разделять ситуации, когда разработчик имеет смещенный график, и когда он все силы тратит на то, чтобы сделать поставленную перед ним задачу в срок. В любом случае, эта ситуация самая плохая из выше описанных.
  • Если всё сделать общим образом, мы получим не только решение частной задачи, но и готовый программный продукт, который будем продавать другим, и таким образом всё окупим.
    Комментарий: это просто приятные фантазии. Разработка готового продукта стоит примерно в три раза дороже программы для собственных нужд (см. «Мифический человеко-месяц» Фредерика Брукса). Кроме того, никто ведь не изучал рынок на предмет выяснения, а нужен ли такой продукт, и сколько у него сильных конкурентов.
    Мои комментарии: Самая серьезная проблема возникает тогда, когда разработчик пытается обобщать, поскольку не знает всех деталей частного. В этом случае от обобщения нет никакого прока, кроме затягивания сроков выполнения неправильно поставленной задачи.
  • К пятнице готово не будет, но в понедельник — точно. Или во вторник.
    Комментарий: скорее всего и во вторник ничего не будет. В лучшем случае будет не готовая версия, а нечто для показа из рук с объяснениями на пальцах, как всё будет потом.
    Мои комментарии: Самая серьезная проблема возникает тогда, когда разработчик не знает, когда закончит, поскольку столкнулся с проблемами технического или архитектурного характера, которые он не знает, как решать.

И некоторые цитаты из словаря ненормативной лексики руководителя:

  • За проект отвечают Пронькин, Тюлькин и Васькин.
    Комментарий: так не бывает. Шофер у автомобиля должен быть один. Три или пять «ответственных» обязательно развалят проект.
  • Что-то вы много работы насчитали. Выдумываете сложности. Нужно просто напрячься, недельку посидеть ночами и всё сделать! С программистами всегда так. Ты поговори там с ребятами.
    Комментарий
    : так говорит менеджер, не понимающий сути разработки ПО (которая «не резиновая») и не контролирующий ситуацию в проекте (который скорее всего уже сорван).
    Кстати, это точная цитата «из жизни».
  • Загруженность Петрова по нашему проекту 57%, а Сидорова — 15%.
    Комментарий: обычно подобные дробные значения загруженности используют в системах управления проектами (или просто в Microsoft Excel) для «точного подсчета» ресурсов.
    Я как-то не очень верю в подобные расчеты. Жизнь устроена так, что чаще всего 15% на самом деле равняются 0%, а 57% превращаются в 100% или 120%. Лучше всего, когда под проект выделена полностью занятая в нем рабочая группа, которая изредка дергает другие обслуживающие отделы.

Обсуждение закрыто.