Комментарии 158
21. Все ваши навыки, знания дизайна, все вышеперечисленные пункты, умение программировать, отличный продукт и сатисфакция от завершенной микросистемы не имеют смысла, если ее не смогут кому-то продать и заставить как можно больше людей пользоваться результатом вашего труда. Без знаний маркетинга и продаж в купе с изучением целевой аудитории любой проект - мертворожденный. Sad but true.
Свободный контент и свободное ПО никому не продаётся. Оно свободное. Поэтому этим контентом и софтом пользуется как можно больше людей.
В свободном ПО тоже нужна популяризация, "продать" его миру. Это и документация и удобство использования, и поддержка.
От того, что больше пользователей будут пользоваться любым ПО, жизнь программиста лучше не станет (банально потому, что придется исправлять больше ошибок). Так может не в этом дело?
Тут нужно погружаться в дебри дискуссии "как от количества пользователей зависит зарплата обычных программистов". К томуже есть куча стартапов, которые прожигают деньги инвесторов, не имея ни одного клиента, и закрываются незадолго после выхода продукта на рынок. По вашим словам, именно из таких стартапов должны появляться самые лучшие программисты
Ну хорошо, пусть не "самые лучшие", а "самые счастливые" например. Все равно вообще не очевидно
Тут скорее не к моим словам нужно придираться, а к вашим. Так как изначальный комментарий ваш.
И вы написали, что "больше пользователей" будет что-то там. Но во-первых, под "продать" не всегда подразумевает под собой миллиард пользователей. Если вы продадите свои наработки только лишь майкрософту или гуглу, возможно, одного этого хватит намного больше, чем если продать наработку миллиарду человек.
То что "продавать" больно, вне зависимости от значения этого слова - да, потому что придется исправлять больше ошибок в продуктах. Если вы пишете что-то в стол, и думаете, что так и должно быть, ну это какбы "зона комфорта" из которой "нужно выйти" (ненавижу это выражение, но здесь оно как раз в тему). И то, что вы делаете это в ОпенСурс, ни на что не влияет. Программист в стартапе может быть также счастлив, что на него не взваливают обязанности править ошибки. А может быть наоборот несчастлив. Также как ОпенСурс программист. Так что вопрост тут был, к чему ваш комментарий, а не мой
О миллиарде пользователей я тоже не писал.
И я не писал
Вот вырезаете вы, положим, кораблики из дерева
А вы вырезаете? Я не знаю. А почему? Потому что, даже если и вырезаете, то на публике нигде не показываете. Зачем тогда проекты в OpenSource выкладываете?
К тому, что утверждение «в опенсорсе тоже нужна популяризация» неверно
Вы каждый день популяризируете Haskell/Idris :)
Лан
Я как раз утверждал обратное, что миллиарды пользователей не нужны
Потому что создать репку на гитхабе сильно проще
Приватные репы никто не отменял
Потому что я так могу продемонстрировать свои навыки (программиста, не аналитика) потенциальному работодателю
Это и называется продажа
Но это не значит, что я буду прикладывать какие-то специальные усилия для того, чтобы проект был кому-то полезным
Далеко не всегда продажа про пользу :)
или чтобы те, кому проект будет полезным, про него узнали.
А почему бы и нет?
наделяет меня некоторыми обязанностями
Да никто и нигде не наделяет никакими обязонностями. В частности и по другим пунктам статьи. Но вы прицепились почемуто именно к этому
При этом я не являюсь разработчиком ни того, ни другого.
Не обязательно быть разработчиком, чтобы что-то продать
Ну и ещё чем больше людей будет пользоваться приятными мне языками программирования, тем лучше будет моя жизнь
О. Дошли до того, что вы так отрицали
Зачем это утверждать, если тезис про миллиард пользователей никто не высказывает?
Я думал, вы подразумеваете миллиард пользователей, когда говорите "от большего количества пользователей увеличится количество денег у меня на счету" или "Ну и ещё чем больше людей будет пользоваться приятными мне языками программирования". Ну если нет, так нет
Я на гитхабе прмерно с декабря 2007-го
Не знаю насчет гитхаба, но на томже битбакете бесплатные приватные репы можно было завести уже давно. Не знаю, с какого года, но сильно раньше, чем на гитхаб.
Это продажа себя
Тем не менее. Какая разница, что продается. В опенсурс тоже не продукт продается (обычно, обычно, давайте не цепляться за излишнее обобщение, ок?) а поддержка например
А про что?
Ну ок, не до конца сформулировал, грешен. Я отвечал на этот тезис "чтобы проект был кому-то полезным" и имел в виду, что продажа не всегда приносит пользу покупателю, что ж поделаешь. Продавцу как правило да, пользу приносит.
Зачем мне прилагать целенаправленные усилия, чтобы про неё узнавали?
Ваше право. Хотите, прилагайте, хотите нет. Странно в одной фразе утверждать, что ваши наработки полезны, а в другой, что нет. Ну не полезны, значит не продвигайте.
Во-первых, здесь утверждается о любом свободном ПО
"Переходя дорогу, посмотрите сначало налево, потом направо". Прям на любой дороге? И на дороге с односторонним движением? И на заброшенной дороге? И на трапинке? И на детской железной дороге тоже? Кто эти правила составлял? Расстрелять всех, смущают только простой народ
Вы снова путаете квантор существования с квантором всеобщности
Только ситхи всё возводят в абсолют. Вот любите вы придумывать излишние обобщения на ровном месте и тутже их опровергать. Вот вообще неспортивное поведение. Даже в науке или математики нет цели опровергнуть выдуманное утверждение, а есть цель докопаться до истины. Не представляю, как вы наукой занимаетесь
К томуже заметил противоречие
про то, чтобы моё ПО было полезным, и так далее, но с опытом (вот прям как писал комментатор выше) я понял, что это всё ерунда, так как это гордыня, и это слишком сильно убивает мои нервные клетки
Вы каждый день популяризируете Haskell/Idris
Ну и ещё чем больше людей будет пользоваться приятными мне языками программирования, тем лучше будет моя жизнь
Тоесть вы желаете автору яп своей участи?
в опенсорсе тоже могут оказаться полезными навыки продажи, если вам важно, какое количество людей пользуется вашим продуктом
Неправильно. Уже обсуждали, что количество пользователей не сильно важно. Можно например продовать продукт компаниям (да в большинстве случаев я полагаю в опенсурсе и продается компаниям).
Переформулируйте.
Давайте-давайте, интересно, как у вас получится правильно
Как и всегда, ваш ответ абсолютно точен и абсолютно бесполезен. Вы хоть сами поняли, что хотели этим ответом сказать? Почему тогда не придумать миллиард подобных ответов?
Если вы хотите, чтобы ваш проект отправился в космос, вам возможно потребуются навыки продажи.
Если вы хотите, чтобы ваш проект не съел кракен, вам возможно потребуются навыки продажи.
Если вы хотите, чтобы ваш проект не продавался, вам возможно потребуются навыки продажи.
Что тут останавливаться-то?
Да и вообще, речь была не о вас, а об опенсорсе в целом.
Тут, как в известном анекдоте, ваш ответ абсолютно точен и абсолютно бесполезен. Ну очень странно отрицать, что opensource проекты имеют продажников в том числе. И да, всегда можно найти контрпример, но ради чего? Можно например найти человека, который генерирует смишьные надписи в таблице активности на гитхабе. Он тоже будет опенсурс разработчиком?
необязательно - большое число пользователей скачавших ваш софт с "torrents.РУ" не принесет денег, зато принесет проблемы с отзывами на плохую работу и ошибки.
большое число пользователей - потребует затраты на комманду поддержки, и реакцию на заявки - затраты на устранение проблем
Они ещё откажутся покупать новую версию ПО, так как предыдущая их вполне устраивает )))
От того, что больше пользователей будет пользоваться моим ПО, моя жизнь лучше не станет.
Вы уверены?
К примеру, у Линуса Торвальдса жизнь явно стала лучше, именно от того что очень большое количество пользователей пользуется первоначально разработанным им программой: он занимается своим любимым (ну, разве что, оно ему успело надоесть) делом и явно не испытывает недостатка в деньгах.
За все остальное не скажу, но внешне он явно в шоколаде.
PS Есть очень интересная тема — финансирование разработки ПО: как показывает практика, в нашей реальности она не исчерпывается банальной продажей программного продукта AKA коммерческое ПО.
Ну так сколько этих Линусов Торвальдсов, а сколько — обычных людей, которые просто что-то там по вечерам и выходным пописывают в опенсорс?
Показываю, почему ваше возражение не годится, а для этого немного переформулирую по аналогии:
сколько этих Биллов Гейтсов, а сколько — обычных владельцев мелких фирмочек, делающих коммерческое ПО или, там, разработчиков shareware?
То есть, на слуху у нас, конечно, только нечто масштабное, но этим индустрия отнюдь не ограничивается. Я, вот, к примеру лично знаю человека, который зарабатывал деньги на свободном ПО, как минимум, ещё с 1998 года: тогда он делал интернет-проекты для небольшой фирмы, где я работал, ну а сечас дорос до руководителя вполне заметной в России фирмы, которая как раз на свободном ПО зарабатывает.
Вы о донатах или о чём-то ещё?
Не только. Я же не зря писал, что тема очень интересная.
Если вкратце (статью я писать-то не готов): механизмов финансирования разработки ПО много. Это могут быть и пожертвования частных лиц, и всякие государственные и полугосударственные фонды, и производители оборудования (типа IBM — именно они лет 15-20 назад очень сильно поддерживали Linux), и поставщики интернет(они же — облачные)-услуг, использующие ПО. Ну и всегда остаются производители ПО заказного или полузаказного (требующего значительной доработки под конкрретного заказчика) — без них крупный (а в особых случаях — и не крупный) бизнес не может удовлетворить свои специфические потребности.
Более того, со временем господствующий механизм меняется. В 50-70-е годы им было перераспределение прибылей производителей оборудования — IBM AKA Big Blue и другие, — для которых ПО для их оборудования было побочным продуктом, повышающим ценность их основного продукта. В 80-00-е этим механизмом стала продажа отчуждаемого программного продукта — в чем особо преуспела всем известная Microsoft. А в наше время значительную роль в финансировании ПО играют как раз поставщики услуг через Интернет.
Как-то так.
Да. Потому что "продавать" (здесь точнее, наверное — "продвигать") и "зарабатывать" не то, чтобы совсем сопадают, но, по крайней мере, довольно сильно коррелируют.
Но вообще-то неплохо было бы ещё и определиться, что имеется в виду под словом пользователи
Вы сами попросили оппонента расскрыть вопрос заработка на ОС и почемуто удивились, когда он этот вопрос заработка раскрыл :)
Хм, то есть хорошая документация, удобный интерфейс - это только при продаже надо делать? Забавно получается - хочешь продать пиши удобную документацию. Не хочешь продавать - пиши, что хочешь?
Как по мне - не продавать надо, а создавать стандарты, которые как раз буду людям объяснять как и почему лучше, а не как продать побольше. Тогда и не будет выбора между "красиво, удобно" и "эффективно, функционально". Возможно тогда будет решать не маркетинг, а качество, эффективность и набор возможностей. И возможно тогда не будет кучи бесполезного, однотипного софта, каждый выполняющий только ограниченый набор функций, причём не имеющий общих функций, или имеющий, но каждый решающий только часть из того, что может потребоваться пользователю =)
На мой взгляд, мысль имеет право на жизнь.
Хм, то есть, мне не может понравится продукт, или он не может просто решать поставленные задачи?
Увы, как мне кажется не всё продаётся! Я выбрал Линуксовую ось не из-за маркетинга, а потому что другая ось не предоставляет мне возможности, которые я хочу иметь. И мне не продавали линукс, а просто сказали, что в это системе возможно то, что мне нужно. И не рекламой =)
Так что приводить в пример СПО, в контексте "продажи", а значит цепляя понятие "маркетинг" - ну оч спорное суждение =)
Вот "окно" - да согласен, прям всё построенно на маркетинге. Да, согласен с автором статьи - если целимся не на пользователей - терям не только прибыль, но и публику. Будь линукс дружелюбным, как та же макось (на секундочку unix подобная система), будь у него маркетинг и экосистема - вы бы сидели на линукс и также рассуждали, про него. Но увы - этого вего нет у линукса и он просто решает задачи пользователя. Да, на нём тоже можно заработать, но за использование Линукса - кто-то платит? За использование FreeBSD - ничего не просят. Много людей знают о FreeBSD или OpenBSD? Хм, сомневаюсь, что в данном случае маркетинг их спасёт. Продавать то нечего =)
P.s. RedHat не был коммерческим первоначально и разрабатывался и хайпил за счёт сообщества, а не маркетинга. Уже после появления коммерческого продукта появилась свободная Fedora (которая не так популярна), и уже после они стали зарабатывать и хайпить. Думаю с остальными из списка была похожая ситуация. И, где TenserFlow?
Если вам вдруг станет интересно - статья на хабре (https://habr.com/en/company/redhatrussia/blog/351170/) + можете почитать, что об этом пишут в сети =)
В обратную сторону это работает точно так же. Нельзя продать отсутствующий продукт. Пограничные случаи типа мошенничества или инвестиции в расчёт не берём. Речь про здесь и сейчас. И даже более того, знания маркетинга не стоят ровным счётом ничего при проектировании сверхтяжёлой ракеты.
Продать несуществующий продукт можно, называется "предзаказ". И первые партии новых продуктов зачастую именно так и продаются.
А вот технологически совершенный существующий продукт который никому не нужен - продать действительно не выйдет, сколько не пытайся.
знания маркетинга не стоят ровным счётом ничего при проектировании сверхтяжёлой ракеты.
МБ потому что всю работу по маркетингу уже кто-то проделал и выкатил ее результаты в виде технических требований и бюджетов?
Техтребования - это маркетинг? Тогда уменьшение - отрицательный рост. Даже ответить нечего на такую логику.
Ок, а откуда вы их тогда возьмете? Ориентироваться-то на заказчика/клиента надо. Того, кто деньги в общем будет платить. Да, можно предположить, что на рынке есть только один потенциальный заказчик на разработку сверхтяжелой ракеты в лице родного государства. Но за доставку грузов на орбиту платить уже готовы многие. И их мнение, а также конкурирующие предложения при проектировании неплохо бы учитывать.
Привет Гагарину передайте и маркетингу в СССР, и гонке вооружения. Ага маркетинг. Конечно, полететь в космос - это маркетинг. Чёт интересно Америка именно поэтому свою космическую программу создала? Ракеты Маска поэтому многоразовые? Потому что пиарится надо или потому что так выгодней? Мы теперь маркетингом будем ТТХ обосновывать? Лол.
Чес слово, вот что что, а ракета не маркетинг. Маркетинг - это "Наша ракета летает быстрее других, в ней есть печеньки". Я думаю когда Гагарин полетел первый раз в космос его не печеньем и комфортом и функциональностью затащили, а тем, что есть идея, есть желание человека покарить и увидеть космос, первому там оказаться (вот тут да маркетинг). Что теперь будем делать сотню разных ракет и доказывать друг другу у кого комфортней? Или просто опишем общий стандарт и позволим по-разному конфигурировать? Мне кажется второе куда логичней первого, и имеет как минимум большую эффективность и пользу для общеста, нежели пилить сотню ракет и каждую всем вокруг презентовать как лучший вариант. Конкуренция не есть хорошо, хорошо - это когда сделано эффективно, красиво и удобно - или проще говоря оптимально.
Вы зря так обижаетесь на маркетинг. Печеньки для него — это лишь частный случай продвижения товара. И то скорее на b2c рынке.
А вообще маркетинг — это процесс сбора информации о рынке (кто наш покупатель, что ему нужно, те же конкуренты), а затем процесс продвижения товара (в случае b2b какие-нибудь встречи, выставки, информационные буклеты, рассрочка и прочие спецпредложения). И даже самые крупные производители оборудования нисколько этого не стесняются. Можете хоть на авиаотрасль посмотреть. Да и у того же Маска пиара в деятельности хоть отбавляй. В любом его бизнесе, кстати. Не говоря уж о том, что технические решения вроде используемых материалов и возвратности ориентированы как раз на определенные сегменты рынка полетов на орбиту.
Да собственно второй пункт как раз про это.
Отнюдь. Можно создать идеально подходящий продукт, но люди будут продолжать пользоваться менее удобным, но привычным, для решения этой же проблемы - просто потому что они не знают про Ваш продукт, и сарафанное радио может не спасти. Нужно уметь рассказать людям об этом продукте, так чтобы они услышали и захотели попробовать.
Хм, то есть идеально подходящий продукт надо тоже продавать? Тогда не идеальный он. Если просто описание функций, которые работают идеально, интерфейса, который идеальный и невероятно удобный, и производительность, которую непривзащёл никто другой так как она у нас идеальная - не хватает? Это тогда что нужно сделать чтобы пользователь захотел его использовать? Машину каждому дарить?
Мне кажется покажи свою программу в сравнение с другими, и не обязательно только на киллер фичах - и народ потянется. Не рекламой всё таки надо а в целом выбором того, что решает твою проблему.
Мне кажется покажи свою программу в сравнение с другими, и не обязательно только на киллер фичах - и народ потянется.
Вот Вы сами говорите - программу нужно показать. Иначе люди просто не узнают про неё. Сарафанное радио - это хороший способ распространения, бесплатный, надёжный... но очень медленный.
Можно сделать идеальный продукт, сделать идеальное описание, выложить его на гитхабе - но никто о нём не узнает. Пусть он идеально решает какую-то проблему, но люди привыкли использовать для её решения условный Excel - и они продолжат им пользоваться. Возможно, первый раз с ней столкнувшись, они и попробуют погуглить варианты решения. Но они не будут это делать каждый раз, снова решая эту проблему.
Не обязательно давать платную рекламу, может быть, достаточно будет написать статью на хабр, с описанием нового чудо-решения.
Здесь, я считаю, должно быть разделение труда. Инженеры не должны заниматься маркетингом или продажами, для этого должны быть специальные компетентные люди, к мнению которых надо прислушиваться. См. также п.п. 2 и 3.
Много маркетологов знают Фортран и используют его в своей работе? Многих маркетологов вы знаете которые используют Фортран для решения повседневных задач? Мне кажется если мы будет инструменты рекламировать разработчикам - то это уже не разработчики, а какие-то работники уровня секретарей, которые сморят тупо на статистику и принимают решения. Когда это сфера IT стала смотреть на маркетинговую состовляющую инструмента, а не на то, что этот самый инструмент способен решить? Когда это инструменты стал важнее решения задачи оптимальным способом, а не "Нет смузи на логотипе, поэтому не буду использовать". Забавно получается, не правда ли?
Достаточно просто оценить, насколько вообще у компании хорошо идут дела с этим делом, для этого особых знаний не надо по маркетингу.
Во втором пункте об этом упоминалось
Самое сложное в разработке — сделать продукт, который действительно нужен
...можно разработать самую технически впечатляющую вещь в мире, а потом никто не захочет её использовать...
Это пп. 2 и 5 в сумме и чуть под другим углом ;)
Нет и нет. Продукт может быть нужен, но о нем никто не знает и "когда-нибудь он выстрелит" здесь не работает. Пятый же пункт - он о целях, а не о успешности проекта. Банальный пример - софт интерактивного управления ракетами, написанный дома, и успешно протестированный на клубных моделях, но после - закинутый на полку. Работает? - Да. Цели добился? - Да. Нужен? - Не известно (но вероятнее всего - очень). Заброшен и не развивается? Да. Весь букет. И таких проектов у каждого увлеченного программиста - есть о чем поговорить.
А зачем продавать-то, если продукт, например, внутренний или для специфической аудитории? Или - вообще бесплатный?
Деньги - не единственная ценность для бизнеса и разработчика
Так что - да и да :)
"Продать" != "Деньги". Откуда такая жесткая фиксация на том, что "продать" - это сразу деньги?
Нет, продать - это значит убедить человеков пользоваться. Именно этим и занимается маркетинг софтварного продукта. А что у вас там есть какие-то возвышенные цели или маленькие аудитории - уже вторично. Если проект не развивается, у него нет пользователей, нет новых возможностей апдейтов и реакции на изменения снаружи - он мертв. Даже если выполняет свои цели здесь и сейчас.
Я об этом писал, а не о ваших деньгах. Смотрите, пожалуйста, дальше кончика своего носа и своих меркантильных интересов.
Dixi.
Вы бы умерили пыл и были бы поосторожнее с формулировками - вас заносит в хамство.
Далеко не всегда надо убеждать пользоваться - иногда выбор делается административным путем или в силу отсутствия альтернатив.
И да - проект может не развиваться и, при этом, быть живее всех живых - мир сложнее и не такой черно-белый, как вы пытаетесь представить ;)
И - снова про хамство. Ваша пылкость и приверженность некоей идее его ни разу не оправдывает.
Sapienti sat.
Давайте не переходить на личности. Я вам не хамил, но в том числе предложил смотреть дальше и знакомиться с темой обсуждения глубже. Потому как она действительно намного глубже и обширнее чем "я продал боссу Х строк кода". Не понимаю, почему вы восприняли это, как хамтво, но все же - прошу прощения.
Спасибо, есть о чем подумать
А как вы определили, что это ботовод? Я просто думал, одобрять или не одобрять пустой коммент, и представил, что это живой человек, и что ему, наверное, странно, почему его за approve-wall вдруг отправили (и тут есть ещё комменты от очевидно живых людей, которым был нужен аппрув). Решил, что одобрить будет меньшим злом.
Соблюдайте, пожалуйста, адекватную тональность при дискуссии.
Программист - не небожитель, а член команды. И понимать весь процесс крайне полезно всем членам команды.
Чем больше программисты понимают большую картину, включая процесс доставки заказчику и использование заказчиком, тем меньше очевидных ошибок при разработке, которые всплывают только в реальной работе.
Вообще немного сбоку есть. Например, понимание кто твой покупатель дает возможность лучше продумать этап сборки и распространения приложения. А этот этап уже может быть технический и в том числе частью разработки.
Знание маркетинга является той сферой, которую должен понимать разработчик, если его ПО работает в сфере маркетинга. Аналогично тому, как разработчик в сфере медицины имеет знания из области медицины, в сфере банкинга - знания по банкингу и т.д.
В любом случае небольшие знания из смежной области еще никому не вредили и зачастую позволяют делать свою работу более качественно и эффективно.
Пример. Ваша целевая аудитория: люди с ограниченным зрением (думается на таком примере понятнее всего будет, надеюсь)
Теперь расскажите, насколько разработчику должно быть всё равно и не его дело знать о целевой аудитории и о том как продукт будет продаваться (с технической точки зрения, а не маркетинговой).
А то мне рисуется картина, как пандусы у нас делают, по которым если спустишься - еще больше инвалидом станешь. Не, ну а что, там же строители, не их забота думать о целевой аудитории и том, как их продукт использоваться будет.
И конечно же, если для вас программист - это тот кто код набирает, то вы безусловно правы в своих суждения. Однако для меня программист - это инженер, и его главный навык - умение анализировать и находить решение.
Смотрите, в нормальном мире есть такой специальный человек, менеджер продукта, который 1) знает как надо 2) может записать это знание в виде спецификации 3) может найти общий язык с инженером, совместно с ним эту спецификацию привести к виду, пригодному к техническому воплощению.
Это задача менеджера продукта - влезть в шкуру пользователя и понять, какие у него потребности и пути их удовлетворения.
Смотрите, в нормальном мире есть средний и малый бизнес и команды из двух-трех человек.
И далее, чтобы ваш "специальный специалист" мог найти общий язык с инженером, то этот специалист либо должен быть сам инженером, либо инженер иметь немного знаний из области "специального специалиста".
Также я нигде не писал, что информацию должен собирать программист - у него своя работа, но чтобы эту информацию воспринять и воспринять максимально правильно - знания области, из которой приходит информация - дает огромную фору.
Всё смешали. Речь не о маркетинге больше. Программисту хорошо бы задумываться кто и как будет пользоваться ПО, но ни как о том, как его продать.
Вы, наверное, из тех разработчиков, которые тесты тоже не пишут, потому что это задача QA? А задачи программистов – исключительно писать код и больше ничего?
Ну да очень удобно, может тогда давайте маркетологов и продажников попросим программировать? А то они недостаточно понимают весь процесс.
Программисты по долгу службы должны уметь разбираться в любой неведомой херне, но желание иметь full-full-full stack программистов не больше чем желание сэкономить.
Да я могу сделать продукт от начала до конца, но связка из квалифицированного ВA, Dev, Sec, QA, Ops сделает более качественный продукт быстрее. Эффективность конвеера еще никто не отменял.
С моей точки зрения знать про маркетинг и продажи и заниматься маркетингом и продажами это разные вещи. Заниматься маркетингом и продажами это действительно дело специалистов и только их, но вот если программист не знает ничего про маркетинг и продажи, то может получиться как у Райкина "К пуговицам претензии есть? Нет, пришиты крепко не оторвать. Только не там"
Настоящий маркетолог (ТМ) продаст и такое (как у Райкина). И покупатель ещё счастлив будет, что купил эксклюзив в "стиле Малевича".
Всё-таки маркетинг - это совсем друга степь. Что программист действительно должен знать и уметь, так это потребности и интересы пользователя (в т.ч. и "истинные" - о которых и сам пользователь изначально не знает, но скажет спасибо). Но это не маркетинг - это часть искусства проектирования.
В широком смысле предназначение маркетинга состоит в «определении и удовлетворении человеческих и общественных потребностей»
— Wiki
В рамках широкого определения, понимание потребностей и интересов пользователя так же входит в маркетинг, это и предлагается знать программисту. И это утверждение совпадает с контекстом утверждения в статье.
Вы не совсем правы, это как раз и есть одна из самых важных частей маркетинга. И, кстати, маркетинг совсем не равен искусству продавать, он скорее дает информационную базу для продажи
А ПМ на что? А Менеджеры зачем? То есть командой руководить - это к программистам. Тестировать - то же должны знать. Как продукт продавтать - к программистам тоже должны знать. Как пользователи его используют - тоже к программистам. А ЧЁ другие делать должны?
Ну так вот именно, что "не небожитель", а член команды у которого есть чёткие задачи, а не ворох непонятно чего. Есть задача сделать красивый интерфейс? Идите к дизайнерам, пускай рисуют, после собираем команду и все вместе обсуждаем. Обсуждение должно идти в ключе как сделать, например, быстрее, чтобы раньше выпустить продукт и тогда мы обращаемся к разработчику, которые сообщает какой диз он сделал быстрее или что можно оптизимировать (убрать или уменьшить), чтобы выпустить его раньше. Он не должен решать какой интерфейс лучше, он должен дать свою оценку с точки зрения Разработчика, что позволит выпустить продукт в срок или очень близко к сроку, что потребует больше усилий и так далее. Тут появляется менеджер по рискам, а параллельно в общение разработчика и диза, заходит UX/UI специалист + тестировщик и каждый даёт свою оценку, из чего мы составляет некоторую сводную таблицу и ПМ решает, что будет и как. Опять же советуясь и обсуждая, а не "Разраб решай"!!!
Перечитал ещё раз так задевший Вас комментарий, но нигде не нашел в нем утверждения, что маркетингом и продажами должны заниматься инженеры и программисты.
Вы абсолютно точно обозначили разницу между программистом и разработчиком: программиста не должны волновать маркетинг, дизайн и продажи. А хорошего разработчика должны.
12 пункт - прям в точку. На моей прошлой работе стали внедрять CRM, штука вроде всем нужная и полезная, но такое сопротивление сильное и инженеров и продажников было(у каждого нашлась своя причина не любить систему), что в какой-то момент руководство на все приличия и политкорректность плюнуло и стало внедрять систему быстро и жестоко - буквально огнем и мечом...
Я видел 10х программистов. Иногда и сам такое делал. Впрочем и были у меня проекты, где я был 0.1х , а то и хуже. Как говорил Козьма Прутков -"нельзя объять необъятное". Иногда требуются специфические знания или опыт далёкие от программирования. Кроме того есть проекты, которые один человек может сделать, а другой никогда. И как в таком случае соотносится их производительность?
Это тогда не 10х называется, а узкий специалист. И его производительность можно измерять хоть как-то только среди таких же узких специалистов. Ибо в чём то другом он будет, вероятно, только 0.5х. Или 0.264х. ну тут как повезет...
При этом узкий специалист не просто x10 по скорости, но и по качеству результата.
Порой меня посещает мысль, что фуллстек - это как единорог, - слово есть, а в природе не существует. А тех кого называют этим словом не более чем лошади, к которым бутофорский рог нацеплен, и все меряются на ком этих колпачков больше)
Может быть и 10х и 1000х программист, все зависит от задачи, она может просто быть не по зубам человеку и все.
Все зависит от задач, и временного горизонта, на котором это мерять — разница в среднем за 10 лет видимо будет не такой большой, как на отдельно взятой задаче. Но именно одна отдельно взятая задача иногда может решить, будет ли проект успешен, или провалится.
Ну как раз разница в том что можно и выгодно автоматизироватьТут есть нюанс — кому выгодно. Если это выгодно владельцу бизнеса, то это отнюдь не значит, что будет выгодно рядовым наемным работникам — скорее, наоборот.
Так что Петя с Колей по жизни, бывает, не только сами не автоматизируют, но и к такому Васе относятся, как шахтеры из песни Высоцкого «Случай на шахте» к тамошнему «стахановцу-гагановцу-загладовцу», которого в шахте завалило:
Спустились в штрек, и бывший зэк — Большого риска человек — Сказал: «Беда для нас для всех, для всех одна: Вот раскопаем — он опять Начнёт три нормы выполнять, Начнёт стране угля давать, и нам хана. Так чтобы, братцы, не стараться, А поработаем с прохладцей — Один за всех и все за одного». …Служил он в Таллине при Сталине — Теперь лежит заваленный, Нам жаль по-человечески его.
Каждый пункт точен и прекрасен. Особенно нравится пункт про 10х программистов. Легко создавать эффект крутого программиста, когда просто многократно применяешь один и тот же код. Это кажется таким быстрым. Сколько раз такое было - сидит большая группа, пилит какое-нибудь решение месяцами, а ты приходишь, прикручиваешь немножко своего готового кода - и ускакиваешь на белом коне с рюкзаком денег под грустные взгляды неудачников. Но постепенно твои наработки устаревают и ты становишься опять 1х программистом. И не обязательно везет второй раз, хотя серии - вполне возможны. Только я таких 1000х программистов называю внедренцами. Ну, у нас в 1с так принято :)
Ну рано или поздно пытливый программист-интегратор обрастает жирком собственного фреймворка ( инструментом автоматизации и упрощения). Главное вовремя уловить момент, когда жирок начинает мешать двигаться. А в 1с, по моему субъективному опыту доработок и интеграций, самоперенастраивающиеся минные поля от версии к версии.
Поговорите с окружающими, запросите фидбек и советы.
Не-а, не так все просто. Неразговорчивый программист скажет "норм", и на этом разговор закончится. Возможно, он правда понял задачу, а может и нет, но не думает, что стоит спрашивать.
В целом статья хорошая и я согласен практически со всем изложенным.
Но к сожалению, данные советы мало помогут тому, кто не имеет подобного опыта. Чтобы делать обобщения нужно для начала иметь "то", что обобщать, и это главное, что есть у автора. А для человека, который не прошел подобного пути, эти 20 пунктов будут просто набором красивых фраз, так как не имеют под собой основы.
Вообщем, как и в геометрии, здесь "царских" путей нет.
аналитический паралич
Какое точное определение хорошо знакомого чувства. :)
Хороший термин, факт ;-)
Основные принципы agile:
люди и взаимодействие важнее процессов и инструментов;
работающий продукт важнее исчерпывающей документации;
сотрудничество с заказчиком важнее согласования условий контракта;
готовность к изменениям важнее следования первоначальному плану.
В статье, как мне кажется, больше имеется в виду Scrum.
Попробую отстоять точку зрения автора статьи, исходя из своего опыта. IMHO, Agile - это про гибкость огранизации в контексте проиходящих изменений, возможность реагировать на feeback и делать pivot-ы. Перечисленные вами принципы являются советами, помогающими этого достичь. Упомянутые автором разбиение работы на порции - наиболее простым и часто используемым способом увеличить гибкость, управляемость и предсказуемость. Но если просто свести весь Agile к четырём принципам, будет следующее (реальные случаи):
"Работающий софт важнее документации, be agile!" - произносит менеджер, отвественный за спецификацию к сложной технической системе. А когда он пишет-таки спецификацию перед самым релизом, выясняется, что там написано "как хотелось бы", а не "как есть" - а соответствующие переделки займут пару месяцев.
"Люди важнее процессов" - заявляет организация и внедряет Agile. Из 32 человек команды разработки продукта с 1.5 миллионами клиентов за два месяца увольняются 29, которым не понравился такая передовая методология.
Под соусом "заказчик важнее контракта" были пропихнуты изменения, на реализацию которых были брошены все ресурсы. После чего заказчик начал угрожать иском на круглую сумму из-за того, что не было сделано то, что было указано в контракте (вот же сюрприз!).
"Важнее" - это не "абсолютный приоритет над".
Примеры неправильного понимания принципов не делают сами принципы неправильными.
Можно говорить про принципы аджайла, а внедрять дичь. Дичь от этого аджайлом не станет. Ну и перед внедрением любых принципов всё же стоит подумать. Аджайл не виноват в том, что под его маской делают всякое и без ума.
Кодерские будни
Не легка программистская доля,
Много разных подводных камней,
И порой за столом как в забое,
Но и нравится мне это в ней.
Когда словно в плаще и настроен
Будто сыщик Эркюль Пуаро,
Ты в дебагере ставишь брейкпоинт,
Но не стопится что-то оно.
С удивлением смотришь на листинг,
По прошествии нескольких дней,
Разобраться к чему в коде фистинг
Безуспешно порой, хоть убей.
Почему переменных названья,
Состоят лишь из нескольких букв,
Не неся за собой пониманья,
Принося столько кодерских мук.
Почему же мой код как спагетти,
Ведь писалось всё модульно, тля.
И зачем указатели эти,
Без проверки остались ноля.
В этих дебрях сам чёрт ногу сломит,
Я себе уже три поломал,
Всё без тестов на честном хардкоде,
Автор, видимо, гидроцефал.
Кто в проект притащил крокодила,
И зачем-то покрасил его?
Кто, скажите мне, этот чудила?
Нет, за зеркалом нет никого!
Вы на что это тут намекнули?
Мол во всём этом я виноват?
Я в аджайл-обойме как пуля,
Хотя хочется мне в водопад.
По поводу 10х программистов у меня есть пример. Одна весьма большая компания поставляет довольно сложные программно-аппаратные комплексы. В какой-то момент один из заказчиков при заказе новой системы просит реализовать несколько специфических фич - там список из полутора десятков пунктов. И там реально ну месяца на два работы. Но менеджмент решает не реализовывать их в существующем продукте, а решает заменить "легаси" софт полностью новой разработкой. В одной жаркой стране нанимается одиннадцать программистов и им даётся 55 недель (это реальные цифры). На постройку железа нужно примерно девять месяцев. Через год выясняется, что команда программистов даже близко не подобралась к решению задачи. Заказчик же, получив систему с "легаси" программой, логично спрашивает "ну и где мои фишки?". Тогда в срочном порядке возвращаются к старому продукту, одинокий программист в одной европейской стране уходит в глубокий оффлайн и три недели пилит код, затем летит через океан в одну заснеженную страну и там ещё за три недели доводит всё до состояния, как нужно заказчику. Прямо на месте, выполняя тестирование прямо на системе и используя самого заказчика как бета-тестера. По итогу заказчик доволен неимоверно - он получил всё, что хотел и даже больше. Производительность - один к ста - за шесть недель реализовано то, с чем не справились за 600 человеконедель. Это разумеется не означает, что программист работал в сто раз быстрее, просто он точно знал "куда бить". А почему команда в десять раз больше не справилась - так это всё у Фредерика Брукса описано. Вот как-то так. Тут, конечно, можно поговорить о том, как всё это потом поддерживается, но по итогу за три года заказчик нашёл один баг и попросил ещё одну маленькую опцию, так что результат норм. Я хочу лишь сказать, что эти мифические 10х обычно получаются когда сравнивается производительность индивидуального и очень опытного программиста, видящего цельный продукт, с отдельным программистом из команды, работающей в общем абсолютно неэффективно.
То, что 1 человек может быть эффективнее 10 - вполне возможно. За счет опыта, за счет лучшего понимания предметной области, за счет более глубоких знаний о конкретном продукте.
То, что 1 человек может быть эффективнее 10 при прочих равных - вот это уже миф, о чем и говорится в 10 пункте (правда раскрывается эта мысль в статье по приведенной ссылке).
Разве бывает так, что прочие равны? Обычно ситуация такая, что про прочие равные можно сказать о бесполезных программистах, с 0ой эффективностью. Да и вообще я очень редко встречал команды, где все программисты опытны и понимают предметную область. Обычно это один человек, и все остальные простые исполнители без своей головы на плечах.
Первым среди шакалов быть не сложно, но ведь куда интереснее бежать впереди львов. ;) Если ты конечно не антилопа.
Интересно как фирма отблоагодарила одинокого северного программиста, который буквально спас продукт. Не оказалось что "100" программист окажется в 1000 раз дороже?
Это сказ не про программирование, а про управление разработкой. С таким же успехом могли нанять 1000 землекопов, чтобы сделать IT-систему за 55 недель
Очень режет слух словосочетание "инженер-программист". Ну вот как можно назвать инженером, например джуна, который только и знает что один язык и то на уровне нескольких решенных задач? Это начинающий программист + "наименования языка программирования". Инженер - ну это уж вовсе слишком ёмкое понятие. А вот инженер-программист, на мой взгляд, это человек, который разбирается в оборудовании (читайте электротехнике), знает технологию и при всем этом может написать надежный код. И не стоит путать последнего с сисадмином пожалуйста.
А как же пункт, где хороший программист должен развернуть бинарное дерево, слева на право, за 10 мин, на клочке туалетной бумаги, стоя на одной ноге?
Лично я вполне готов поверить, что такие люди существуют. И это вовсе не должно означать, что человек действительно работает в 10 раз быстрее (не рассматриваю сейчас случай узкоспецифичных задач, когда один просто знает решение, а другой вообще не сталкивался с подобным). Просто нужно смотреть комплексно и на длинной дистанции.
Человек может работать «всего лишь» в 2 раза быстрее среднего по больнице сотрудника, а остальное добирать косвенными выгодами. Он может давать более высокое качество кода и архитектурных решений. Он задает правильные вопросы и упреждающе избегает многих граблей. Его код содержит меньше ошибок, лучше поддерживается, легче расширяется. Меньше тратится времени тестировщиков и менеджеров.
Кроме того, условные 5 высококвалифицированных инженеров будут тратить намного меньше времени на совещания, чем 50 низкоквалифицированных, разбитых на несколько команд с промежуточными начальниками и пр. В одной из книг Перельмана я читал, что восьмерка лошадей развивает реальную среднюю мощность около 3,5 лошадиных сил — из-за рассинхрона усилий.
И вот если собрать всё в комплексе, разница в 10 раз не выглядит чем-то невозможным.
Основная работа любого инженера-программиста — предоставление ценности.
Очень режет слух фраза, я бы перевёл как «обеспечение (материальной) отдачи».
И в самом начале есть фраза:
You need to build everything as microservices!” says the company who built a quick monolith,…
Интересно, что означает этот «quick monolith»?
16 пункт отличный, очень редко кто это понимает
Печальненько! Это я о комментариях: не все прочитал, но похоже, что большинство не поняли духа статьи. Именно духа, а не смысла. А этот дух заключается в том, что автор описал как он стал счастливым человеком. Оказывается, что для этого не обязательно больше продать или содрать с заказчика больше денег.
20 вещей, которые я узнал за 20 лет работы инженером-программистом