TwitterПочему не надо потакать инженерам и программистам
Posted on May 7th, 2007 by Max Kraynov
Как некоторые читатели этого блога знают, в своей предыдущей жизни я был программистом Java + Oracle и кучи других баз данных. Так что я знаю, насколько неприятно программистам будет читать нижеизложенное. Программистов с ранимой психикой просьба не читать дальше.
Я обнаружил классную статью, указывающую на недостатки технологических компаний (на примерах производителей сотовых телефонов). Вот кое-какие выжимки из этой статьи (переведённые либо пересказанные мною), которыми нельзя не поделиться:
- В инженерах часто упорство и желание работать много сочетается с упёртостью и отказом делать то, что просят.
- Когда инженер говорит, что что-то сделать невозможно, ты тратишь неделю, чтобы понять, является ли проблема ограничением технологии или нежеланием инженера сделать то, что ты просишь. Как правило, это последнее.
- Когда инженер говорит, что что-то сделать возможно, результат будет запутанным и трудным в использовании.
- Продукты тогда только хороши, когда ими пользуются (МК: это я говорю на каждой встрече с инженерами в нашей компании, и, по-моему, народ это всё ещё не понимает).
- Требовать покупателя читать многостраничные описания продукта (в статье приведены примеры мобильных телефонов) перед покупкой – это идиотизм.
В общем, здравая статья, написанная человеком, работающим на похожей со мной позиции в другой компании. Уверенное одобрям-с!
Filed under: Бизнес
Подписаться по Email
Если не читал еще книгу “Психбольница в руках пациентов”, то прочитай обязательно. На редкость толковая и как раз на эту тему.
Спасибо за наводку. К сожалению, книги на русском достать возможности не имею, разве что только в онлайне прочитать. А так – название очень даже захватывающее.
Нашёл!
Вот она. Побежал заказывать.
Думаю что пост навеян прочтением Getting Real 🙂
Все хорошо в меру, комбинация организационного и творческого решения проблем, лучший тому пример. Помимо разработки ИТ подразделениям нужно осваивать и новые подобласти применения продукта.
На самом деле проблема сугубо историческая. В тот момент когда пользователями стали люди без технического образования она сформировалась, до инженеров (программистов) не доходит и никогда не дойдет, что требуется пользователю быстрое решение проблемы, а не чтение документации и т.д.
Мы, допустим, при разработке под заказ просто слизываем текущий алгоритм работы пользователя, а потом постепенно подтачиваем, либо по его желанию, либо в интересующую нас сторону, но постепенно.
В представленный список маразмов можно добавить еще возможность гибкой настройки и поиск максимально гибкого решения и то и другое приводит к пагубным последствиям. (как не программист)
Все остальное говорю как участник процесса со стороны программистов.
Пример из моего сегодняшнего рабочего дня. Проект стоимостью около 600к был обещан группе внутренних и внешних клиентов. Сроки срывались три раза, т.к. разработчики хотели сделать всё гибко и круто (насколько это возможно сделать в Индии).
3 недели назад моя продуктовая группа взялась за оценку ущерба. Подсчитали – прослезились. Периодически делаем теперь reality checks, привлекая наших клиентов и sales staff. Ну и что? Сегодня, за 3 недели до официальной сдачи, выяснилось, что народ хочет немного другого, и та гибкая функциональность, которую напихали программисты, нафиг не нужна.
PS. Из серьёзных советов из Getting Real можно найти только один главный: надо уметь делать быстрые итерации. (По этому принципу был построен мой старый бизнес, и теперь, в моей новой компании со штатом в 25 раз больше, я насаждаю тот же принцип). Но это недёшево.
Но это на порядок дешевле чем искать гибкости. При том что за гибкость как правило редко платят. Я не знаю, имхо, конечно, но я уже забыл когда заходил в настройки программы кроме почтового клиента и пары приложений для прописывания прокси. Нужно чтобы работало быстро и четко, иначе это уже не работа, а саботаж с умным лицом.
Немного спорно. У нас масштаб продуктов такой, что функция ценой в неделю и 5 тысяч долларов может за 1 день окупиться. Мы позволяем гонять mobile campaigns практически любой сложности – что страшно неповоротливо на этапе настройки, но страшно выгодно на этапе получения денег.
Макс, а у тебя нет часом списка действенных мер воздействия на программистов, дабы получать продукт, а не не нужную никому функциональность?
Мы говорим про большой коллектив или про маленький?
Маленький коллектив (7-8 человек) из Unwiredtec-а почти не нуждался в управлении. Они прекрасно знали, что если что-то пойдёт не так, то никто не будет кушать.
Сейчас я собственно разработкой не руковожу, а руковожу продуктовым отделом, который общается с клиентами, придумывает продукты и функции, делает описания и спецификации продукта – и только после это программисты начинают делать архитектуру и писать код. В результате, программисты не делают бизнес-решений (которые они делать не умеют и посему не должны), а лишь строгают код и исправляют ошибки. Это у нас стало работать, хотя это стоило нам огромных нервов.
На ту же тему:
http://www.ashmanov.com/pap/ashrul.phtml
“Правила Ашманова” – очень грамотное произведение, с правотой которой я в большей части соглашаюсь (мне не приходилось попадать в ряд ситуаций, куда приходилось попадать Игорю, поэтому 100% сказать не могу про правильность/неправильность). Интересно также то, что эти правила работают для компаний из разных стран, не только России. Ну и, конечно же, что 90% этих правил описаны в любой книжке, посвящённой PMP.
[…] я бы не позволял инженерам/придумывателям рулить мною […]
[…] рекомендации интересами бизнеса”. Так и есть, многих программистов больше интересуют технические и …. Случается ли это из-за того, что зачастую технология – […]
интересно, а как так получается, что девелоперы могут менять бизнес требования? Есть упрощенно “ability to have” список требований который легко (относительно разработки) чекается. Я сознаю, что нужна определенная гибкость в архитектуре или баланс между хардкодом и конфигурированием (упрощенно). Но вся эта гибкость должна аппруваться грамотным и опытным архитектором (или тим лидом) разбирающимся в рисках; и один из самых главных рисков пролететь со сроками или бюджетом (т.е. когда нечего показать и нечего сказать в свое оправдание), и тогда нечего будет кушать хе-хе… IMHO
Я несколько знаком с наиболее распространенными методологиями проектирования и разработки 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 действительно талантливый в техническом плане человек, обладающий обширными знаниями и имеющий большой опыт в разработке.