Почему не надо потакать инженерам и программистам

Как некоторые читатели этого блога знают, в своей предыдущей жизни я был программистом Java + Oracle и кучи других баз данных. Так что я знаю, насколько неприятно программистам будет читать нижеизложенное. Программистов с ранимой психикой просьба не читать дальше.

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

  • В инженерах часто упорство и желание работать много сочетается с упёртостью и отказом делать то, что просят.
  • Когда инженер говорит, что что-то сделать невозможно, ты тратишь неделю, чтобы понять, является ли проблема ограничением технологии или нежеланием инженера сделать то, что ты просишь. Как правило, это последнее.
  • Когда инженер говорит, что что-то сделать возможно, результат будет запутанным и трудным в использовании.
  • Продукты тогда только хороши, когда ими пользуются (МК: это я говорю на каждой встрече с инженерами в нашей компании, и, по-моему, народ это всё ещё не понимает).
  • Требовать покупателя читать многостраничные описания продукта (в статье приведены примеры мобильных телефонов) перед покупкой — это идиотизм.

В общем, здравая статья, написанная человеком, работающим на похожей со мной позиции в другой компании. Уверенное одобрям-с!

Подписаться по Email

16 комментариев to “Почему не надо потакать инженерам и программистам”

  1. Если не читал еще книгу «Психбольница в руках пациентов», то прочитай обязательно. На редкость толковая и как раз на эту тему.

  2. Спасибо за наводку. К сожалению, книги на русском достать возможности не имею, разве что только в онлайне прочитать. А так — название очень даже захватывающее.

  3. Нашёл!

    Вот она. Побежал заказывать.

  4. Думаю что пост навеян прочтением Getting Real 🙂

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

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

    Мы, допустим, при разработке под заказ просто слизываем текущий алгоритм работы пользователя, а потом постепенно подтачиваем, либо по его желанию, либо в интересующую нас сторону, но постепенно.

    В представленный список маразмов можно добавить еще возможность гибкой настройки и поиск максимально гибкого решения и то и другое приводит к пагубным последствиям. (как не программист)

    Все остальное говорю как участник процесса со стороны программистов.

  6. Пример из моего сегодняшнего рабочего дня. Проект стоимостью около 600к был обещан группе внутренних и внешних клиентов. Сроки срывались три раза, т.к. разработчики хотели сделать всё гибко и круто (насколько это возможно сделать в Индии).

    3 недели назад моя продуктовая группа взялась за оценку ущерба. Подсчитали — прослезились. Периодически делаем теперь reality checks, привлекая наших клиентов и sales staff. Ну и что? Сегодня, за 3 недели до официальной сдачи, выяснилось, что народ хочет немного другого, и та гибкая функциональность, которую напихали программисты, нафиг не нужна.

    PS. Из серьёзных советов из Getting Real можно найти только один главный: надо уметь делать быстрые итерации. (По этому принципу был построен мой старый бизнес, и теперь, в моей новой компании со штатом в 25 раз больше, я насаждаю тот же принцип). Но это недёшево.

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

  8. Немного спорно. У нас масштаб продуктов такой, что функция ценой в неделю и 5 тысяч долларов может за 1 день окупиться. Мы позволяем гонять mobile campaigns практически любой сложности — что страшно неповоротливо на этапе настройки, но страшно выгодно на этапе получения денег.

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

  10. Мы говорим про большой коллектив или про маленький?
    Маленький коллектив (7-8 человек) из Unwiredtec-а почти не нуждался в управлении. Они прекрасно знали, что если что-то пойдёт не так, то никто не будет кушать.

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

  11. На ту же тему:
    http://www.ashmanov.com/pap/ashrul.phtml

  12. «Правила Ашманова» — очень грамотное произведение, с правотой которой я в большей части соглашаюсь (мне не приходилось попадать в ряд ситуаций, куда приходилось попадать Игорю, поэтому 100% сказать не могу про правильность/неправильность). Интересно также то, что эти правила работают для компаний из разных стран, не только России. Ну и, конечно же, что 90% этих правил описаны в любой книжке, посвящённой PMP.

  13. […] я бы не позволял инженерам/придумывателям рулить мною […]

  14. […] рекомендации интересами бизнеса”. Так и есть, многих программистов больше интересуют технические и …. Случается ли это из-за того, что зачастую технология — […]

  15. интересно, а как так получается, что девелоперы могут менять бизнес требования? Есть упрощенно “ability to have” список требований который легко (относительно разработки) чекается. Я сознаю, что нужна определенная гибкость в архитектуре или баланс между хардкодом и конфигурированием (упрощенно). Но вся эта гибкость должна аппруваться грамотным и опытным архитектором (или тим лидом) разбирающимся в рисках; и один из самых главных рисков пролететь со сроками или бюджетом (т.е. когда нечего показать и нечего сказать в свое оправдание), и тогда нечего будет кушать хе-хе… IMHO

  16. Я несколько знаком с наиболее распространенными методологиями проектирования и разработки IT индустрии.
    Из этого теоретического и своего практического-Java-программистского опыта могу сказать, что научить людей следовать интересам компании можно следующим образом:
    1. используя спецификации требований (естественно, они у всех есть, но качество их сильно отличается), закрепить все требования в документальном виде
    2. ткнуть носом каждого разработчика в SRS (Software Requirements Specification)
    3. конечно же, обязательно нужен грамотный архитектор или tech lead, который будет фильтровать все технические решения и оценивать их рисковость для проекта.

    Дело в том, что мой непосредственный начальник сейчас, tech lead проекта, именно так и делает. Все проектные решения идут через него (особенно глобальные, которые часто он ветирует, так как они тупо не вписываются в бюджет).
    Еще мне очень нравится его практика — делать code review 1-2 раза в неделю на каждого из разработчиков нашей Java-команды (сейчас в ней 6 человек). Code review состоит в том, что каждый получает письмо с XLS (MS Excel) файлом, в котором содержатся рекомендации и исправления, которые увидел tech lead при просмотре закоммиченного в SVN кода. Это повышает качество кода, решений, экономит время (так как происходит через почту).
    Дело в том, что эти все практики применимы и дают какой-то результат (а у нас это отличный результат) только в том случае, если этот tech lead действительно талантливый в техническом плане человек, обладающий обширными знаниями и имеющий большой опыт в разработке.