Упрятанный под кат текст появился под влиянием недавнего обсуждения в FB и свежей заметки ув.тов.kaa.python. Тема "правильного" инструмента для достижения успеха у программистов очень актуальна. Была актуальна в прошлом, является актуальной сейчас и вряд ли утратит актуальность в будущем. Так что можно сказать на эту тему пару слов.
На самом деле ответы уже были даны классиками. А именно Фредериком Бруксом -- "Серебряной пули не существует", а так же Томом ДеМарко и Тимоти Листером, которые указывали в "Человеческом факторе", что для любого инструмента есть удачный и неудачный опыт его применения.
Можно, конечно, не верить этим именитым авторам и считать, что их время давным давно прошло, что сейчас все изменилось... Только вот все это самообман. Нет инструментов, которые бы гарантировали успех продукту или компании (в особенности, если речь идет о стартапах). Коммерческий успех в очень малой степени обуславливается технологическими факторами, тут есть гораздо более важные вещи, начиная от сплоченности команды, харизматичности лидера, четкости целей и заканчивая элементарной удачей.
Так что если кто-то думает, что можно взять технологию X и это обеспечит хотя бы 50% ожидаемого успеха, то пора расстаться с иллюзиями :) Скорее всего из-за собственной зашоренности (что характерно для погруженных в технические детали программистов) вы просто не осознаете, сколько всякого разного и разнообразного влияет на итоговый результат. Программистам может быть неприятно осознавать, но удачливый продажник с хорошими связями может дать в копилку компании гораздо больше, чем самый крутой архитектор ПО. Такова жизнь :)
Означает ли это, что технология вообще не важна?
Нет, конечно же. Технология важна.
Неверно выбранная технология способна похоронить проект/компанию. Но удачно выбранная технология может обеспечить лишь небольшое конкурентное преимущество. Что, вообще-то говоря, очень и очень не мало. Нужно только суметь этим воспользоваться.
Анализируя свой и чужой опыт, я для себя сделал такой вывод: стартуя новый продукт, особенно в условиях стартапа, следует выбирать тот инструмент, которым вы и ваши коллеги-соучастники владеете в совершенстве. При условии, конечно, что этот инструмент в принципе может использоваться для решения подобных задач: вряд ли есть смысл писать очередной движок Интернет-магазина на C++, как и нет смысла разрабатывать видеоконвертер на PHP.
Почему важно уверенное владение инструментом? Потому, что у вас не будет времени на изучение чего-то нового, на набивание шишек, на поиск готовых решений и т.д. В условиях стартапа, даже когда есть четкий план движения вперед, нет на это времени. Еще хуже, когда все очень динамично меняется и сегодняшние приоритеты совсем не такие, как вчера.
Тут все просто: либо вы можете быстро воплотить свои мысли в работающий код, либо нет. Чем лучше вы владеете инструментом, тем более быстрый темп способны поддерживать, тем меньше усилий и времени уходит в пустоту. Чем хуже владеете, чем меньше готовых фреймворков и библиотек имеется в вашем распоряжении, тем хуже для вас.
Очевидно, что мейнстримовые технологии в этом плане выглядят наиболее привлекательно. Значит ли это, что в условиях стартапа нужно смотреть в первую очередь на старые и проверенные вещи. Например, брать Java вместо Scala или Clojure?
На мой взгляд -- нет. Имхо, чуть больше шансов у вас будет, если вы выберете что-то между замшелым мейнстримом и совсем уж откровенной маргинальщиной. Что-то, что уже на слуху и успело обрасти жизнеспособным коммьюнити, но пока еще не стало полноценным мейнстримом.
Попробую пояснить, почему я так думаю.
Самая главная причина -- люди. Люди, которые хотят и могут создавать что-то новое, а ведь речь идет о разработке нового продукта, они немного отличаются от всех остальных. У них шило в заднице, неистребимое стремление к чему-то новому (ну или просто необычному). Таким людям просто скучно в мейнстриме. И возможность попробовать что-то новое будет для них дополнительным стимулом. Причем очень сильным. Такие стимулы за деньги не продаются :)
Причем перспективная технология не только служит мотиватором для тех людей, которые уже сидят в вашей обойме. Эта технология еще и будет работать как приманка и как фильтр, привлекая и пропуская лишь тех, кто с наибольшей вероятностью удачно встроится в вашу команду уже по ходу развития проекта.
Есть и еще один фактор, про который говорят не так часто. И который имеет две стороны. Фактор этот -- отсутствие готовых шаблонов и устоявшихся практик. С одной стороны -- это плохо, т.к. для любой проблемы вам самим придется искать решение. С другой стороны -- это хорошо, т.к. нет стереотипов и соблазна применить паттерн X просто потому, что он на слуху и им удачно пару раз воспользовались в прошлом. В итоге в новом проекте на немейнстримовой технологии приходится много велосипедить. Но это как раз нормально, ведь что такое новый проект? Тот же самый велосипед, про который еще даже не известно, поедет ли он или нет. А если и поедет, то не на квадратных ли колесах с кучей подпорок? ;)
Кроме того, не нужно упускать из виду тот факт, что выжившие технологии, пусть даже не очень раскрученные, содержат в себе некоторое рациональное зерно и в них есть какие-то немаловажные отличия от конкурентов. И если такие отличия есть, то почему бы не использовать их себе во благо? Тем более, что разработка нового -- это всегда жуткий напряг и цейтнот, тут любое, даже самое мелкое конкурентное преимущество облегчает продвижение вперед.
В общем, если судьба дает вам шанс начать делать что-то свое и с нуля, то имеет смысл оглядеться по сторонам и с особым пристрастием рассмотреть инструменты, которые уже выросли из детских штанишек, хотя махровым мейнстримом еще не стали. Попробуйте стать или early adopters, или early majority, т.е. людьми, идущими на осознанный риск ради достижения некоторых технологических преимуществ.
Правда я не знаю, скольким из прочитавших данную заметку читателям такой шанс выпадет хотя бы раз в жизни. Особенно во времена варварского и массового аутсорсинга, царящего сейчас на просторах СНГ :(
Еще несколько вещей напоследок.
Во-первых, не следует остро реагировать на широкотиражируемые новости о том, что "компания Y использует технологию Z и получает невероятный профит". Ведь есть еще фиг знает сколько других компаний с технологий Z на борту, но которые и близко не приблизились к шумному успеху компании Y.
Во-вторых, технология, на которой был достигнут первоначальный успех, не обязательно сможет выжить в дальнейшем. Ведь спринтерский забег (стартап) в корне отличается от стайерского (неторопливое поступательное развитие успешной компании). Люди, которые стояли у истоков стартапа, куда-нибудь уйдут: либо вверх, либо в сторону. На их смену придут разработчики и управленцы совсем с другими качествами, другой психологией, другими целями. Да и чисто технические условия могут измениться при росте масштабов. Так что полное постепенное переписывание продукта (или его частей) на других инструментах -- это нормально. Достаточно вспомнить Yahoo Store (было на Lisp-е, стало на C++), Facebook ChatApp (было на Erlang, стало на C++), Twitter и LinkedIn (было на Ruby, стало на Scala/Java).
В-третьих, таки на счет C++. Как по мне, C++ за последние годы смещался из категории мейнстрима в сторону маргинальщины. Так что сейчас C++ как раз близок к той самой категории не-мейнстрим-и-не-маргинальщина, инструменты из которой хороши для старта чего-то нового. Так что запуск новых проектов на C++ (как и разработка инструментария для C++), на мой взгляд, довольно-таки оправданная вещь. Знаю, что многие со мной не согласятся, но мне как-то пофигу. Ведь коммерческий успех нового продукта практически не зависит от использованной для разработки этого продукта технологии :)
Комментариев нет:
Отправить комментарий