Почему не надо потакать инженерам и программистам
Как некоторые читатели этого блога знают, в своей предыдущей жизни я был программистом Java + Oracle и кучи других баз данных. Так что я знаю, насколько неприятно программистам будет читать нижеизложенное. Программистов с ранимой психикой просьба не читать дальше.
Я обнаружил классную статью, указывающую на недостатки технологических компаний (на примерах производителей сотовых телефонов). Вот кое-какие выжимки из этой статьи (переведённые либо пересказанные мною), которыми нельзя не поделиться:
- В инженерах часто упорство и желание работать много сочетается с упёртостью и отказом делать то, что просят.
- Когда инженер говорит, что что-то сделать невозможно, ты тратишь неделю, чтобы понять, является ли проблема ограничением технологии или нежеланием инженера сделать то, что ты просишь. Как правило, это последнее.
- Когда инженер говорит, что что-то сделать возможно, результат будет запутанным и трудным в использовании.
- Продукты тогда только хороши, когда ими пользуются (МК: это я говорю на каждой встрече с инженерами в нашей компании, и, по-моему, народ это всё ещё не понимает).
- Требовать покупателя читать многостраничные описания продукта (в статье приведены примеры мобильных телефонов) перед покупкой - это идиотизм.
В общем, здравая статья, написанная человеком, работающим на похожей со мной позиции в другой компании. Уверенное одобрям-с!
Subscribe to MaxKraynov by Email
May 7th, 2007 at 8:37 pm
Если не читал еще книгу “Психбольница в руках пациентов”, то прочитай обязательно. На редкость толковая и как раз на эту тему.
May 7th, 2007 at 8:38 pm
Спасибо за наводку. К сожалению, книги на русском достать возможности не имею, разве что только в онлайне прочитать. А так - название очень даже захватывающее.
May 7th, 2007 at 8:39 pm
Нашёл!
Вот она. Побежал заказывать.
May 8th, 2007 at 3:38 pm
Думаю что пост навеян прочтением Getting Real
Все хорошо в меру, комбинация организационного и творческого решения проблем, лучший тому пример. Помимо разработки ИТ подразделениям нужно осваивать и новые подобласти применения продукта.
May 9th, 2007 at 2:49 pm
На самом деле проблема сугубо историческая. В тот момент когда пользователями стали люди без технического образования она сформировалась, до инженеров (программистов) не доходит и никогда не дойдет, что требуется пользователю быстрое решение проблемы, а не чтение документации и т.д.
Мы, допустим, при разработке под заказ просто слизываем текущий алгоритм работы пользователя, а потом постепенно подтачиваем, либо по его желанию, либо в интересующую нас сторону, но постепенно.
В представленный список маразмов можно добавить еще возможность гибкой настройки и поиск максимально гибкого решения и то и другое приводит к пагубным последствиям. (как не программист)
Все остальное говорю как участник процесса со стороны программистов.
May 9th, 2007 at 3:00 pm
Пример из моего сегодняшнего рабочего дня. Проект стоимостью около 600к был обещан группе внутренних и внешних клиентов. Сроки срывались три раза, т.к. разработчики хотели сделать всё гибко и круто (насколько это возможно сделать в Индии).
3 недели назад моя продуктовая группа взялась за оценку ущерба. Подсчитали - прослезились. Периодически делаем теперь reality checks, привлекая наших клиентов и sales staff. Ну и что? Сегодня, за 3 недели до официальной сдачи, выяснилось, что народ хочет немного другого, и та гибкая функциональность, которую напихали программисты, нафиг не нужна.
PS. Из серьёзных советов из Getting Real можно найти только один главный: надо уметь делать быстрые итерации. (По этому принципу был построен мой старый бизнес, и теперь, в моей новой компании со штатом в 25 раз больше, я насаждаю тот же принцип). Но это недёшево.
May 10th, 2007 at 4:58 am
Но это на порядок дешевле чем искать гибкости. При том что за гибкость как правило редко платят. Я не знаю, имхо, конечно, но я уже забыл когда заходил в настройки программы кроме почтового клиента и пары приложений для прописывания прокси. Нужно чтобы работало быстро и четко, иначе это уже не работа, а саботаж с умным лицом.
May 10th, 2007 at 7:41 am
Немного спорно. У нас масштаб продуктов такой, что функция ценой в неделю и 5 тысяч долларов может за 1 день окупиться. Мы позволяем гонять mobile campaigns практически любой сложности - что страшно неповоротливо на этапе настройки, но страшно выгодно на этапе получения денег.
May 14th, 2007 at 4:14 am
Макс, а у тебя нет часом списка действенных мер воздействия на программистов, дабы получать продукт, а не не нужную никому функциональность?
May 14th, 2007 at 7:02 am
Мы говорим про большой коллектив или про маленький?
Маленький коллектив (7-8 человек) из Unwiredtec-а почти не нуждался в управлении. Они прекрасно знали, что если что-то пойдёт не так, то никто не будет кушать.
Сейчас я собственно разработкой не руковожу, а руковожу продуктовым отделом, который общается с клиентами, придумывает продукты и функции, делает описания и спецификации продукта - и только после это программисты начинают делать архитектуру и писать код. В результате, программисты не делают бизнес-решений (которые они делать не умеют и посему не должны), а лишь строгают код и исправляют ошибки. Это у нас стало работать, хотя это стоило нам огромных нервов.
May 22nd, 2007 at 1:38 am
На ту же тему:
http://www.ashmanov.com/pap/ashrul.phtml
June 3rd, 2007 at 10:04 pm
“Правила Ашманова” - очень грамотное произведение, с правотой которой я в большей части соглашаюсь (мне не приходилось попадать в ряд ситуаций, куда приходилось попадать Игорю, поэтому 100% сказать не могу про правильность/неправильность). Интересно также то, что эти правила работают для компаний из разных стран, не только России. Ну и, конечно же, что 90% этих правил описаны в любой книжке, посвящённой PMP.
July 9th, 2007 at 7:52 pm
[…] я бы не позволял инженерам/придумывателям рулить мною […]
August 21st, 2007 at 4:47 pm
[…] рекомендации интересами бизнеса”. Так и есть, многих программистов больше интересуют технические и …. Случается ли это из-за того, что зачастую технология - […]
December 5th, 2007 at 10:47 pm
интересно, а как так получается, что девелоперы могут менять бизнес требования? Есть упрощенно “ability to have” список требований который легко (относительно разработки) чекается. Я сознаю, что нужна определенная гибкость в архитектуре или баланс между хардкодом и конфигурированием (упрощенно). Но вся эта гибкость должна аппруваться грамотным и опытным архитектором (или тим лидом) разбирающимся в рисках; и один из самых главных рисков пролететь со сроками или бюджетом (т.е. когда нечего показать и нечего сказать в свое оправдание), и тогда нечего будет кушать хе-хе… IMHO