Наткнулся на любопытный материал, в котором автор систематизировал и записал свой опыт инженера-программиста в 20 тезисов. Я работаю в коммерческой разработке ПО больше 25 лет, и этот текст отозвался во мне практически каждой буквой — большинство советов я тоже регулярно практикую, не облекая их в формат ёмких афоризмов. В общем, решил сделать перевод.
Особенно отзываются пункты «стройте компактные системы» и «лучший код — это отсутствие кода». Последний совет я превращаю в цитату из какого-то второсортного фильма про самураев: «Лучшая победа — та, которую ты одержал, не доставая меч из ножен» (думаю, сослуживцы за моей спиной уже закатывают глаза). И, конечно, бесконечные разговоры про легендарных 10x-программистов постоянно хочется прервать советом не связываться с 0,1x-программистами (которые реально существуют, в отличие от 10x).
Дисклеймер от автора оригинальной статьи
Учиться на чужом опыте и ошибках очень важно, но мы часто забываем, что большинство советов имеют контекст, который далеко не всегда учитывается.
«Вам просто нужно повысить цены» — говорит компания, которая 20 лет работала в бизнесе, выставляя поначалу низкие цены для привлечения клиентов.
«Вам нужно внедрять микросервисы» — говорит компания, которая построила монолит, набрала тысячи клиентов и перешла на микросервисы, когда столкнулась с проблемами масштабирования.
Без понимания контекста советы бессмысленны или, что ещё хуже, вредны. Если бы эти компании последовали собственным рекомендациям в начале пути, они, скорее всего, навредили бы сами себе.
Для понимания контекста расскажу, откуда берутся советы в этой статье. Первую половину карьеры я работал инженером-программистом в небольших компаниях и стартапах, потом перешёл в консалтинг и работал в нескольких действительно крупных компаниях. Затем основал Simple Thread, которая выросла из команды 2 человек до 25. 10 лет назад мы работали в основном с малым и средним бизнесом, сейчас — со средним и большим.
Советы в этой статье от человека, который:
почти всегда работал в небольших командах, где приходится делать много, имея очень мало;
ценит работающие решения выше конкретных инструментов;
постоянно начинает новые проекты, но поддерживает ряд систем;
ценит производительность инженера выше большинства других критериев.
Мой опыт за последние 20 лет сформировал отношение к разработке и убедил меня в некоторых утверждениях, которые я оформил в виде списка. Надеюсь, он вам будет полезен.
1. Я все ещё многого не знаю
«Как ты можешь не знать, что такое BGP?» или «Ты никогда не слышал о Rust?» — некоторые из нас не раз слышали подобное.
Причина, по которой многие любят разработку, заключается в том, что мы учимся всю жизнь. И в создании софта есть огромные области новых знаний, которые с каждым днём только растут. Можно десяток лет работать программистом и всё равно иметь огромный пробел в знаниях по сравнению с кем-то, кто также провёл десятилетия в, казалось бы, аналогичной роли.
Чем раньше вы это поймёте, тем быстрее сможете избавиться от синдрома самозванца и с удовольствием учиться у других.
2. Самое сложное в разработке — сделать продукт, который действительно нужен
Знаю, что это уже стало клише, но многие инженеры скептически относятся к данному пункту, поскольку считают, что он обесценивает их труд. Чушь, на мой взгляд. Напротив, этот момент помогает подчеркнуть, в насколько сложной и иррациональной среде нам приходится работать, ведь именно эти аспекты так усложняют нашу деятельность.
Можно разработать самую технически впечатляющую вещь в мире, а потом никто не захочет её использовать. Такое случается постоянно. Проектирование софта часто связано со слушанием — нам приходится быть сразу инженером-программистом, экстрасенсом и антропологом.
Инвестиции в процесс проектирования (с помощью UX-специалистов или путём самообразования) принесут огромные дивиденды. Ведь как реально подсчитать стоимость разработки неправильного ПО? Это гораздо больше, чем просто потерянное время инженера.
3. Лучшие инженеры-программисты думают как дизайнеры
Великие инженеры-программисты глубоко задумываются о пользовательском опыте. Они могут не думать об этом в терминах вроде внешнего или программного API, UI, протокола или любого другого интерфейса. Великие инженеры думают о том, кто будет его использовать, почему он будет использоваться, как он будет использоваться и что важно для пользователей. Учет потребностей конечного потребителя — это залог хорошего пользовательского опыта.
4. Лучший код — это отсутствие кода или код, который не нужно поддерживать
Всё, что нужно сказать: кодеры будут кодить. Если спросить человека любой профессии, как решить ту или иную проблему, он выберет то, что у него хорошо получается. Это просто человеческая природа. Большинство инженеров-программистов всегда будут склоняться к написанию кода, особенно когда нетехническое решение не очевидно.
То же самое относится к коду, который не нужно поддерживать. Инженерные команды часто хотят изобрести колесо, когда оно уже существует. Здесь нужно соблюдать баланс, есть много причин для развития собственных разработок, но остерегайтесь токсичного синдрома «изобретено не здесь».
5. Программное обеспечение — это средство достижения цели
Основная работа любого инженера-программиста — предоставление ценности. Немногие разработчики понимают это, ещё меньше тех, кто это осознает. А ведь осознание приводит к другому способу решения проблем и другому взгляду на инструменты.
Если вы действительно верите, что выбор ПО зависит от цели, то будьте готовы найти «правильный инструмент для работы», который может и не являться софтом.
6. Иногда нужно перестать точить пилу и просто начать пилить
Некоторые сразу бросаются в проблему и начинают писать код. Другие — начинают исследовать и попадают в аналитический паралич. В таких случаях установите дедлайн и начните изучать решения. Вы гораздо быстрее узнаете что-то, когда непосредственно станете решать задачу.
7. Если у вас нет представления о границах возможного, вы не сможете спроектировать хорошую систему
С этим я часто сталкиваюсь, поскольку мои обязанности уводят меня все дальше и дальше от повседневной разработки ПО. Следить за командой разработчиков — огромный объём работы. И если вы не понимаете, на что способна ваша команда, то сможете разрабатывать решения только для самых простых проблем. И опасайтесь тех, кто давно не писал никакого кода.
8. Каждая система в конечном счёте отстой, смиритесь с этим
У Бьерна Страуструпа есть цитата: «Есть только два вида языков: те, на которые все жалуются, и те, которыми никто не пользуется». Это можно распространить и на большие системы. Не существует «правильной» архитектуры, вы никогда не закроете весь техдолг, не разработаете идеальный интерфейс, ваши тесты всегда будут слишком медленными.
Это не оправдание тому, чтобы не делать что-то лучше, а наоборот, способ дать вам перспективу. Меньше беспокойтесь об элегантности и совершенстве, стремитесь к постоянному улучшению и созданию пригодной для жизни системы, в которой вашей команде нравится работать и которая стабильно приносит пользу.
9. Никто не спрашивает «почему» в достаточной степени
Используйте любую возможность поставить под сомнение предположения и подходы, которые «всегда делались так, как надо». В команде появился новый сотрудник? Обратите внимание, где он запутался и какие вопросы задаёт. Поступила заявка на новую функцию, которая не имеет смысла? Убедитесь, что вы понимаете цель и то, что требует эту функциональность. Если не получаете чёткого ответа, продолжайте спрашивать, пока не поймёте.
10. Сосредоточьтесь на том, чтобы избежать 0,1х-программистов, а не найти 10х-программистов
10x-программист — это глупый миф. Идея о том, что кто-то может сделать за 1 день то, что не менее компетентный, трудолюбивый, и такой же опытный программист может сделать за 2 недели, глупа.
Я видел программистов, которые пишут в 10 раз больше кода, а потом вам приходится исправлять его в 10 раз дольше. Кто-то может быть 10х-программистом только в том случае, если вы сравниваете его с 0,1x-программистом — тот, кто тратит время, не просит обратной связи, не тестирует свой код, не рассматривает крайние случаи и так далее. Нужно заботиться, чтобы не допустить 0,1x-программистов в команду, а не искать мифического 10x-программиста.
11. Одно из главных отличий между сеньором и джуном — свое мнение о том, как все должно быть
Ничто не беспокоит меня больше, чем сеньор, не имеющий никакого мнения о рабочих инструментах или о том, как подходить к созданию программного обеспечения. Лучше высказать мнение, с которым я буду категорически не согласен, чем не иметь мнения вообще.
Если вы используете инструменты, но ненавидите их, вам нужно изучить больше. Попробуйте другие языки, библиотеки и парадигмы. Существует мало способов повысить уровень своих навыков быстрее, чем активный поиск того, как другие решают задачи с помощью инструментов и методов, отличных от ваших.
12. Людям не нужны инновации
Люди много говорят об инновациях, но обычно они ищут дешёвые преимущества и новизну.
Если вы действительно привносите новшества и меняете то, что людям привычно — ждите отрицательных отзывов. Но если верите в то, что делаете, и знаете, что это действительно улучшит ситуацию, приготовьтесь к долгой битве.
13. Ваши данные — самая важная часть системы
Я видел много систем, в которых целостность данных держалась в основном на надежде. Любое отклонение от идеального сценария в такой системе, и мы получаем частичные или грязные данные, а работа с такими данными в перспективе превратится в кошмар.
Важно помнить, что данные скорее всего сильно переживут вашу кодовую базу. Приложите усилия, чтобы всё хранилось в порядке, и это окупится.
14. Ищите технологических акул
Старые технологии, которые остались на плаву, — это акулы, а не динозавры. Они настолько хороши, что пережили быстрые изменения, которые постоянно происходят в мире технологий. Заменяйте их только в том случае, если у вас есть очень веская причина. Эти инструменты не будут модными и современными, но позволят выполнить работу без множества бессонных ночей.
15. Не путайте скромность с невежеством
Есть много программистов, которые не высказывают мнения, если их прямо не спросить. Если кто-то не высказывает своё мнение вам в лицо, это не значит, что ему нечего добавить. Иногда самых громких хочется слушать меньше всего.
Поговорите с окружающими, запросите фидбек и советы.
16. Программисты должны регулярно писать
Инженеры-программисты должны регулярно вести блог или дневник, писать документацию и вообще делать всё, что требует от них высокого уровня навыков письменного общения. Письмо помогает думать о проблемах и более эффективно общаться с командой. Это один из важнейших навыков, которым должен овладеть любой программист.
17. Рабочие процессы должны быть минимально энергозатратными
Сейчас все хотят быть agile, но «agile» — это создание вещей небольшими порциями, обучение, а затем итерация. Если кто-то пытается вложить в это гораздо больше, значит, он что-то продаёт. Для этого необязательно переставать помогать сотрудникам или отказываться от отчётности, но вы когда-нибудь слышали, чтобы люди из ваших любимых IT-компаний и масштабных опенсорс-проектов хвалились тем, какой у них клёвый Scrum? Процессы должны оставаться лёгкими и гибкими до тех пор, пока не появится потребность в большем. Доверьтесь своей команде, они всё сделают.
18. Инженеры-программисты, как и все люди, должны чувствовать ответственность
Если вы отвлечёте кого-то от результатов его работы, то он будет меньше заботиться о ней. Это почти тавтология и основная причина, почему кросс-функциональные команды работают хорошо, и почему DevOps стал таким популярным. Дело не только в передаче обслуживания и неэффективности, а в том, чтобы управлять всем процессом от начала до конца и нести прямую ответственность за предоставление ценности.
Дайте группе увлечённых людей полную ответственность за проектирование, создание и выпуск софта (или чего-то ещё) — произойдут удивительные вещи.
19. Собеседования не помогут определить, насколько хорошим членом команды будет человек
Собеседования лучше проводить, чтобы понять, кто такой человек и насколько он заинтересован в нужной области знаний. Пытаться выяснить, насколько хорошим членом команды он будет, — бесполезное занятие.
То, насколько человек умён или осведомлён, также не является хорошим показателем, каким членом команды он станет. Никто не скажет вам на собеседовании, что он будет ненадёжным, жёстким, напыщенным или никогда не будет приходить на собрания вовремя. Некоторые ищут «сигналы» для таких вещей, вроде «Если они спрашивают об отгулах на первом собеседовании, значит, они точно не будут ходить на миты!», но это все ерунда. Если вы опираетесь на подобное, то просто гадаете и отбрасываете хороших кандидатов.
20. Стремитесь к созданию более компактной системы
Есть много факторов, которые будут подталкивать вас к созданию большой системы. Распределение бюджета, невозможность решить, какие функции следует сократить, желание создать «лучшую версию». Все эти вещи очень сильно подталкивают к тому, чтобы сделать слишком много. Нужно бороться с этим.
В процессе разработки вы узнаете так много нового, что в результате итераций получите гораздо более крутой результат. Для многих это крайне трудно.
Ваша история
Вот и всё: 20 лет разработки программного обеспечения превратились в 20 мудрых пунктов. Если согласны или не согласны с мыслями в статье, или если есть, что добавить и чем поделиться — пишите в комментариях.
Комментарии (158)
anonymous
00.00.0000 00:00
vagon333
21.10.2021 21:29+14Программист - не небожитель, а член команды. И понимать весь процесс крайне полезно всем членам команды.
Чем больше программисты понимают большую картину, включая процесс доставки заказчику и использование заказчиком, тем меньше очевидных ошибок при разработке, которые всплывают только в реальной работе.
novoselov
21.10.2021 22:40+17Ну да очень удобно, может тогда давайте маркетологов и продажников попросим программировать? А то они недостаточно понимают весь процесс.
Программисты по долгу службы должны уметь разбираться в любой неведомой херне, но желание иметь full-full-full stack программистов не больше чем желание сэкономить.
Да я могу сделать продукт от начала до конца, но связка из квалифицированного ВA, Dev, Sec, QA, Ops сделает более качественный продукт быстрее. Эффективность конвеера еще никто не отменял.
semennikov
22.10.2021 08:37+2С моей точки зрения знать про маркетинг и продажи и заниматься маркетингом и продажами это разные вещи. Заниматься маркетингом и продажами это действительно дело специалистов и только их, но вот если программист не знает ничего про маркетинг и продажи, то может получиться как у Райкина "К пуговицам претензии есть? Нет, пришиты крепко не оторвать. Только не там"
ksbes
22.10.2021 09:21+3Настоящий маркетолог (ТМ) продаст и такое (как у Райкина). И покупатель ещё счастлив будет, что купил эксклюзив в "стиле Малевича".
Всё-таки маркетинг - это совсем друга степь. Что программист действительно должен знать и уметь, так это потребности и интересы пользователя (в т.ч. и "истинные" - о которых и сам пользователь изначально не знает, но скажет спасибо). Но это не маркетинг - это часть искусства проектирования.
transcengopher
22.10.2021 15:50+1В широком смысле предназначение маркетинга состоит в «определении и удовлетворении человеческих и общественных потребностей»
— WikiВ рамках широкого определения, понимание потребностей и интересов пользователя так же входит в маркетинг, это и предлагается знать программисту. И это утверждение совпадает с контекстом утверждения в статье.
semennikov
23.10.2021 23:41+2Вы не совсем правы, это как раз и есть одна из самых важных частей маркетинга. И, кстати, маркетинг совсем не равен искусству продавать, он скорее дает информационную базу для продажи
mvv-rus
22.10.2021 05:39+7Ну как раз разница в том что можно и выгодно автоматизировать
Тут есть нюанс — кому выгодно. Если это выгодно владельцу бизнеса, то это отнюдь не значит, что будет выгодно рядовым наемным работникам — скорее, наоборот.
Так что Петя с Колей по жизни, бывает, не только сами не автоматизируют, но и к такому Васе относятся, как шахтеры из песни Высоцкого «Случай на шахте» к тамошнему «стахановцу-гагановцу-загладовцу», которого в шахте завалило:Спустились в штрек, и бывший зэк — Большого риска человек — Сказал: «Беда для нас для всех, для всех одна: Вот раскопаем — он опять Начнёт три нормы выполнять, Начнёт стране угля давать, и нам хана. Так чтобы, братцы, не стараться, А поработаем с прохладцей — Один за всех и все за одного». …Служил он в Таллине при Сталине — Теперь лежит заваленный, Нам жаль по-человечески его.
Swiftarrow7
25.10.2021 03:53+1А ПМ на что? А Менеджеры зачем? То есть командой руководить - это к программистам. Тестировать - то же должны знать. Как продукт продавтать - к программистам тоже должны знать. Как пользователи его используют - тоже к программистам. А ЧЁ другие делать должны?
Ну так вот именно, что "не небожитель", а член команды у которого есть чёткие задачи, а не ворох непонятно чего. Есть задача сделать красивый интерфейс? Идите к дизайнерам, пускай рисуют, после собираем команду и все вместе обсуждаем. Обсуждение должно идти в ключе как сделать, например, быстрее, чтобы раньше выпустить продукт и тогда мы обращаемся к разработчику, которые сообщает какой диз он сделал быстрее или что можно оптизимировать (убрать или уменьшить), чтобы выпустить его раньше. Он не должен решать какой интерфейс лучше, он должен дать свою оценку с точки зрения Разработчика, что позволит выпустить продукт в срок или очень близко к сроку, что потребует больше усилий и так далее. Тут появляется менеджер по рискам, а параллельно в общение разработчика и диза, заходит UX/UI специалист + тестировщик и каждый даёт свою оценку, из чего мы составляет некоторую сводную таблицу и ПМ решает, что будет и как. Опять же советуясь и обсуждая, а не "Разраб решай"!!!
perlestius
22.10.2021 19:40Не берусь утверждать, но лично я это воспринял так: "даже если технари создадут отличный проект, если маркетологи не смогут его протолкнуть на рынок, то толку нет". Но тут лучше самого @kibizoidus спросить, что он имел в виду
anonymous
00.00.0000 00:00perlestius
22.10.2021 18:40Перечитал ещё раз так задевший Вас комментарий, но нигде не нашел в нем утверждения, что маркетингом и продажами должны заниматься инженеры и программисты.
anonymous
00.00.0000 00:00
azaFromKaza
24.10.2021 10:03+1Вы абсолютно точно обозначили разницу между программистом и разработчиком: программиста не должны волновать маркетинг, дизайн и продажи. А хорошего разработчика должны.
iiwabor
21.10.2021 21:29+312 пункт - прям в точку. На моей прошлой работе стали внедрять CRM, штука вроде всем нужная и полезная, но такое сопротивление сильное и инженеров и продажников было(у каждого нашлась своя причина не любить систему), что в какой-то момент руководство на все приличия и политкорректность плюнуло и стало внедрять систему быстро и жестоко - буквально огнем и мечом...
Spiritschaser
22.10.2021 11:48стали внедрять CRM, штука вроде всем нужная и полезная
В последние несколько лет что только не внедряют под вилом CRM... Особенно пугают кривые реализации groupware с привязкой к базе и задачам CRM - сто.. Нет, 20 лет назад CRM как-то легче внедрялось.
Sdima1357
21.10.2021 21:35+4Я видел 10х программистов. Иногда и сам такое делал. Впрочем и были у меня проекты, где я был 0.1х , а то и хуже. Как говорил Козьма Прутков -"нельзя объять необъятное". Иногда требуются специфические знания или опыт далёкие от программирования. Кроме того есть проекты, которые один человек может сделать, а другой никогда. И как в таком случае соотносится их производительность?
Racheengel
22.10.2021 00:11Это тогда не 10х называется, а узкий специалист. И его производительность можно измерять хоть как-то только среди таких же узких специалистов. Ибо в чём то другом он будет, вероятно, только 0.5х. Или 0.264х. ну тут как повезет...
DeathSAAD
23.10.2021 15:54+1При этом узкий специалист не просто x10 по скорости, но и по качеству результата.
Порой меня посещает мысль, что фуллстек - это как единорог, - слово есть, а в природе не существует. А тех кого называют этим словом не более чем лошади, к которым бутофорский рог нацеплен, и все меряются на ком этих колпачков больше)
sshikov
21.10.2021 22:43Вы просто не до конца дочитали. Там у меня написано «при условии, что их нельзя или невыгодно автоматизировать». Если можно — то разница может быть и больше. Ну т.е. автоматирируемая рутина — это тоже такие задачи, но слегка другого класса.
oOKIBrTlUTohw4Sc
21.10.2021 23:24Ага, главное чтобы это потом не оказался одним из тех инструментов, которые дают 100х его автору и 0.00001х всей команде которая будет это разгребать после его увольнения.
Gorthauer87
21.10.2021 21:39+2Может быть и 10х и 1000х программист, все зависит от задачи, она может просто быть не по зубам человеку и все.
sshikov
21.10.2021 22:36+2Ага. Автору следовало бы помнить простую истину: «Если я чего не видел — это не существует» — не является доказательством. Часто бывает 10х, встречается 100х, все реально зависит от задач — на задачах рутинных у всех вероятно будет близкая производительность (особенно если их нельзя или невыгодно автоматизировать), а на задачах нестандартных, к которым никто не знает, как подойти — вот тут и начинается разница в сроках. В разы и на порядки.
Все зависит от задач, и временного горизонта, на котором это мерять — разница в среднем за 10 лет видимо будет не такой большой, как на отдельно взятой задаче. Но именно одна отдельно взятая задача иногда может решить, будет ли проект успешен, или провалится.
realbtr
21.10.2021 23:23+7Каждый пункт точен и прекрасен. Особенно нравится пункт про 10х программистов. Легко создавать эффект крутого программиста, когда просто многократно применяешь один и тот же код. Это кажется таким быстрым. Сколько раз такое было - сидит большая группа, пилит какое-нибудь решение месяцами, а ты приходишь, прикручиваешь немножко своего готового кода - и ускакиваешь на белом коне с рюкзаком денег под грустные взгляды неудачников. Но постепенно твои наработки устаревают и ты становишься опять 1х программистом. И не обязательно везет второй раз, хотя серии - вполне возможны. Только я таких 1000х программистов называю внедренцами. Ну, у нас в 1с так принято :)
vya
22.10.2021 13:32Ну рано или поздно пытливый программист-интегратор обрастает жирком собственного фреймворка ( инструментом автоматизации и упрощения). Главное вовремя уловить момент, когда жирок начинает мешать двигаться. А в 1с, по моему субъективному опыту доработок и интеграций, самоперенастраивающиеся минные поля от версии к версии.
sshmakov
21.10.2021 23:25+1Поговорите с окружающими, запросите фидбек и советы.
Не-а, не так все просто. Неразговорчивый программист скажет "норм", и на этом разговор закончится. Возможно, он правда понял задачу, а может и нет, но не думает, что стоит спрашивать.
nick1612
22.10.2021 07:49+3В целом статья хорошая и я согласен практически со всем изложенным.
Но к сожалению, данные советы мало помогут тому, кто не имеет подобного опыта. Чтобы делать обобщения нужно для начала иметь "то", что обобщать, и это главное, что есть у автора. А для человека, который не прошел подобного пути, эти 20 пунктов будут просто набором красивых фраз, так как не имеют под собой основы.
Вообщем, как и в геометрии, здесь "царских" путей нет.
no_future
22.10.2021 09:06+3Очень, очень хорошие и правильные советы. Но опыт показывает, что эти советы бесполезны для тех, кто не дошел до них самостоятельно…
trueMoRoZ
22.10.2021 09:18+1Основные принципы agile:
люди и взаимодействие важнее процессов и инструментов;
работающий продукт важнее исчерпывающей документации;
сотрудничество с заказчиком важнее согласования условий контракта;
готовность к изменениям важнее следования первоначальному плану.
В статье, как мне кажется, больше имеется в виду Scrum.
courage_andrey
22.10.2021 10:50+4Попробую отстоять точку зрения автора статьи, исходя из своего опыта. IMHO, Agile - это про гибкость огранизации в контексте проиходящих изменений, возможность реагировать на feeback и делать pivot-ы. Перечисленные вами принципы являются советами, помогающими этого достичь. Упомянутые автором разбиение работы на порции - наиболее простым и часто используемым способом увеличить гибкость, управляемость и предсказуемость. Но если просто свести весь Agile к четырём принципам, будет следующее (реальные случаи):
"Работающий софт важнее документации, be agile!" - произносит менеджер, отвественный за спецификацию к сложной технической системе. А когда он пишет-таки спецификацию перед самым релизом, выясняется, что там написано "как хотелось бы", а не "как есть" - а соответствующие переделки займут пару месяцев.
"Люди важнее процессов" - заявляет организация и внедряет Agile. Из 32 человек команды разработки продукта с 1.5 миллионами клиентов за два месяца увольняются 29, которым не понравился такая передовая методология.
Под соусом "заказчик важнее контракта" были пропихнуты изменения, на реализацию которых были брошены все ресурсы. После чего заказчик начал угрожать иском на круглую сумму из-за того, что не было сделано то, что было указано в контракте (вот же сюрприз!).
SabMakc
22.10.2021 11:00+4"Важнее" - это не "абсолютный приоритет над".
Примеры неправильного понимания принципов не делают сами принципы неправильными.
courage_andrey
22.10.2021 11:46+2Абсолютно верно! Я не против принципов Agile, я против возведения их в абсолют. Собственно, про это и примеры (надеюсь, герои моих примеров икают сейчас).
trueMoRoZ
22.10.2021 14:28Можно говорить про принципы аджайла, а внедрять дичь. Дичь от этого аджайлом не станет. Ну и перед внедрением любых принципов всё же стоит подумать. Аджайл не виноват в том, что под его маской делают всякое и без ума.
vya
22.10.2021 17:17+5Кодерские будни
Не легка программистская доля,
Много разных подводных камней,
И порой за столом как в забое,
Но и нравится мне это в ней.
Когда словно в плаще и настроен
Будто сыщик Эркюль Пуаро,
Ты в дебагере ставишь брейкпоинт,
Но не стопится что-то оно.
С удивлением смотришь на листинг,
По прошествии нескольких дней,
Разобраться к чему в коде фистинг
Безуспешно порой, хоть убей.
Почему переменных названья,
Состоят лишь из нескольких букв,
Не неся за собой пониманья,
Принося столько кодерских мук.
Почему же мой код как спагетти,
Ведь писалось всё модульно, тля.
И зачем указатели эти,
Без проверки остались ноля.
В этих дебрях сам чёрт ногу сломит,
Я себе уже три поломал,
Всё без тестов на честном хардкоде,
Автор, видимо, гидроцефал.
Кто в проект притащил крокодила,
И зачем-то покрасил его?
Кто, скажите мне, этот чудила?
Нет, за зеркалом нет никого!
Вы на что это тут намекнули?
Мол во всём этом я виноват?
Я в аджайл-обойме как пуля,
Хотя хочется мне в водопад.
AndreyDmitriev
22.10.2021 09:36+5По поводу 10х программистов у меня есть пример. Одна весьма большая компания поставляет довольно сложные программно-аппаратные комплексы. В какой-то момент один из заказчиков при заказе новой системы просит реализовать несколько специфических фич - там список из полутора десятков пунктов. И там реально ну месяца на два работы. Но менеджмент решает не реализовывать их в существующем продукте, а решает заменить "легаси" софт полностью новой разработкой. В одной жаркой стране нанимается одиннадцать программистов и им даётся 55 недель (это реальные цифры). На постройку железа нужно примерно девять месяцев. Через год выясняется, что команда программистов даже близко не подобралась к решению задачи. Заказчик же, получив систему с "легаси" программой, логично спрашивает "ну и где мои фишки?". Тогда в срочном порядке возвращаются к старому продукту, одинокий программист в одной европейской стране уходит в глубокий оффлайн и три недели пилит код, затем летит через океан в одну заснеженную страну и там ещё за три недели доводит всё до состояния, как нужно заказчику. Прямо на месте, выполняя тестирование прямо на системе и используя самого заказчика как бета-тестера. По итогу заказчик доволен неимоверно - он получил всё, что хотел и даже больше. Производительность - один к ста - за шесть недель реализовано то, с чем не справились за 600 человеконедель. Это разумеется не означает, что программист работал в сто раз быстрее, просто он точно знал "куда бить". А почему команда в десять раз больше не справилась - так это всё у Фредерика Брукса описано. Вот как-то так. Тут, конечно, можно поговорить о том, как всё это потом поддерживается, но по итогу за три года заказчик нашёл один баг и попросил ещё одну маленькую опцию, так что результат норм. Я хочу лишь сказать, что эти мифические 10х обычно получаются когда сравнивается производительность индивидуального и очень опытного программиста, видящего цельный продукт, с отдельным программистом из команды, работающей в общем абсолютно неэффективно.
SabMakc
22.10.2021 11:10+1То, что 1 человек может быть эффективнее 10 - вполне возможно. За счет опыта, за счет лучшего понимания предметной области, за счет более глубоких знаний о конкретном продукте.
То, что 1 человек может быть эффективнее 10 при прочих равных - вот это уже миф, о чем и говорится в 10 пункте (правда раскрывается эта мысль в статье по приведенной ссылке).
mcpro
22.10.2021 12:29+1Разве бывает так, что прочие равны? Обычно ситуация такая, что про прочие равные можно сказать о бесполезных программистах, с 0ой эффективностью. Да и вообще я очень редко встречал команды, где все программисты опытны и понимают предметную область. Обычно это один человек, и все остальные простые исполнители без своей головы на плечах.
SabMakc
22.10.2021 12:44Вообще - бывает. Это скорее вопрос к компании и ее подходов к построению команд и удержанию сотрудников.
Меньше текучки - больше высококвалифицированных кадров, знакомых с предметной областью и разбирающихся в продукте.
vya
22.10.2021 13:36+2Первым среди шакалов быть не сложно, но ведь куда интереснее бежать впереди львов. ;) Если ты конечно не антилопа.
Goupil
22.10.2021 14:38+1Интересно как фирма отблоагодарила одинокого северного программиста, который буквально спас продукт. Не оказалось что "100" программист окажется в 1000 раз дороже?
botyaslonim
26.10.2021 12:16Это сказ не про программирование, а про управление разработкой. С таким же успехом могли нанять 1000 землекопов, чтобы сделать IT-систему за 55 недель
maynoz
22.10.2021 09:50Очень режет слух словосочетание "инженер-программист". Ну вот как можно назвать инженером, например джуна, который только и знает что один язык и то на уровне нескольких решенных задач? Это начинающий программист + "наименования языка программирования". Инженер - ну это уж вовсе слишком ёмкое понятие. А вот инженер-программист, на мой взгляд, это человек, который разбирается в оборудовании (читайте электротехнике), знает технологию и при всем этом может написать надежный код. И не стоит путать последнего с сисадмином пожалуйста.
SergeAx Автор
22.10.2021 09:54+4engineer /ɛndʒɪˈnɪə/
noun
a person who designs, builds, or maintains engines, machines, or structures.
Так что сисадмин - тоже инженер.
vba
22.10.2021 11:07+2А как же пункт, где хороший программист должен развернуть бинарное дерево, слева на право, за 10 мин, на клочке туалетной бумаги, стоя на одной ноге?
SabMakc
22.10.2021 11:51А "развернуть бинарное дерево" - это просто для всех узлов поменять левое и правое поддерево местами?
На вскидку, 3 поля для описания структуры и строк 10 для алгоритма.
Откуда вообще это пошло, уже не в первый раз встречаю...
Nihiroz
22.10.2021 13:02+1Видимо это объединение двух задач "Развернуть двусвязный список" и "Отбалансировать бинарное дерево"
dom1n1k
22.10.2021 13:43+5Всех зацепил пункт про 10х программистов.
Лично я вполне готов поверить, что такие люди существуют. И это вовсе не должно означать, что человек действительно работает в 10 раз быстрее (не рассматриваю сейчас случай узкоспецифичных задач, когда один просто знает решение, а другой вообще не сталкивался с подобным). Просто нужно смотреть комплексно и на длинной дистанции.
Человек может работать «всего лишь» в 2 раза быстрее среднего по больнице сотрудника, а остальное добирать косвенными выгодами. Он может давать более высокое качество кода и архитектурных решений. Он задает правильные вопросы и упреждающе избегает многих граблей. Его код содержит меньше ошибок, лучше поддерживается, легче расширяется. Меньше тратится времени тестировщиков и менеджеров.
Кроме того, условные 5 высококвалифицированных инженеров будут тратить намного меньше времени на совещания, чем 50 низкоквалифицированных, разбитых на несколько команд с промежуточными начальниками и пр. В одной из книг Перельмана я читал, что восьмерка лошадей развивает реальную среднюю мощность около 3,5 лошадиных сил — из-за рассинхрона усилий.
И вот если собрать всё в комплексе, разница в 10 раз не выглядит чем-то невозможным.
drWhy
22.10.2021 14:36+1Так вот о ком Пушкин баял:
«Ест за четверых,
Работает за семерых;
Досветла всё у него пляшет,
Лошадь запряжет, полосу вспашет...»
barroweer
23.10.2021 01:19Основная работа любого инженера-программиста — предоставление ценности.
Очень режет слух фраза, я бы перевёл как «обеспечение (материальной) отдачи».
И в самом начале есть фраза:You need to build everything as microservices!” says the company who built a quick monolith,…
Интересно, что означает этот «quick monolith»?
ivegner
26.10.2021 20:39+1Полагаю, "быстрый в построении". Такой, построить который не занимает много времени. Не в смысле быстродейственности.
dushinYu
28.10.2021 12:52Печальненько! Это я о комментариях: не все прочитал, но похоже, что большинство не поняли духа статьи. Именно духа, а не смысла. А этот дух заключается в том, что автор описал как он стал счастливым человеком. Оказывается, что для этого не обязательно больше продать или содрать с заказчика больше денег.
kibizoidus
21. Все ваши навыки, знания дизайна, все вышеперечисленные пункты, умение программировать, отличный продукт и сатисфакция от завершенной микросистемы не имеют смысла, если ее не смогут кому-то продать и заставить как можно больше людей пользоваться результатом вашего труда. Без знаний маркетинга и продаж в купе с изучением целевой аудитории любой проект - мертворожденный. Sad but true.
PereslavlFoto
Одно противоречит другому.
Свободный контент и свободное ПО никому не продаётся. Оно свободное. Поэтому этим контентом и софтом пользуется как можно больше людей.
tmin10
В свободном ПО тоже нужна популяризация, "продать" его миру. Это и документация и удобство использования, и поддержка.
0xd34df00d
Кому нужна? Зачем?
От того, что больше пользователей будет пользоваться моим ПО, моя жизнь лучше не станет.
svr_91
От того, что больше пользователей будут пользоваться любым ПО, жизнь программиста лучше не станет (банально потому, что придется исправлять больше ошибок). Так может не в этом дело?
0xd34df00d
Почему? В случае коммерческого ПО (или ПО с платной поддержкой, например) от большего количества пользователей увеличится количество денег у меня на счету.
svr_91
Тут нужно погружаться в дебри дискуссии "как от количества пользователей зависит зарплата обычных программистов". К томуже есть куча стартапов, которые прожигают деньги инвесторов, не имея ни одного клиента, и закрываются незадолго после выхода продукта на рынок. По вашим словам, именно из таких стартапов должны появляться самые лучшие программисты
0xd34df00d
О лучшести программистов я ничего не говорил.
svr_91
Ну хорошо, пусть не "самые лучшие", а "самые счастливые" например. Все равно вообще не очевидно
0xd34df00d
Неочевидно, но вполне возможно.
Впрочем, понимаете, тут какое дело… Изначальный комментатор написал, что свободное ПО тоже нужно продавать миру, что без указания причин и целей этой продажи миру звучит как универсальный тезис. Вы пытаетесь доказать, что не любой программист в стартапе без пользователей счастливее любого программиста с пользователями. Вы ведь понимаете, что кванторы не так работают, и одно не является отрицанием другого?
svr_91
Тут скорее не к моим словам нужно придираться, а к вашим. Так как изначальный комментарий ваш.
И вы написали, что "больше пользователей" будет что-то там. Но во-первых, под "продать" не всегда подразумевает под собой миллиард пользователей. Если вы продадите свои наработки только лишь майкрософту или гуглу, возможно, одного этого хватит намного больше, чем если продать наработку миллиарду человек.
То что "продавать" больно, вне зависимости от значения этого слова - да, потому что придется исправлять больше ошибок в продуктах. Если вы пишете что-то в стол, и думаете, что так и должно быть, ну это какбы "зона комфорта" из которой "нужно выйти" (ненавижу это выражение, но здесь оно как раз в тему). И то, что вы делаете это в ОпенСурс, ни на что не влияет. Программист в стартапе может быть также счастлив, что на него не взваливают обязанности править ошибки. А может быть наоборот несчастлив. Также как ОпенСурс программист. Так что вопрост тут был, к чему ваш комментарий, а не мой
0xd34df00d
Вы опять читаете чьи-то другие комментарии, когда разговариваете со мной. О миллиарде пользователей я тоже не писал.
Сколько открытого ПО продаётся гуглу или майкрософту? Я эту возможность вообще не рассматриваю как имеющую околонулевую вероятность.
Да дело не только и не столько в ошибках (лично у меня, по крайней мере). Баги, в конце концов, чинить требует некоторый внутренний перфекционизм. Дело скорее в том, что придётся разбираться со скучными и неинтересными feature request'ами. Или, например, собирать код со 100500 зависимостями на C++ под Windows, а не только убедиться, что он следует стандартам, и выложить на гитхаб.
Да зачем выходить-то, объясните? Вы в каждом своём хобби выходите из этой зоны комфорта?
Вот вырезаете вы, положим, кораблики из дерева — я правильно понимаю, что вы должны выйти из зоны комфорта, что вы должны работать над тем, чтобы люди хотели их брать (бесплатно, отмечу), что вы должны этим людям (взявшим у вас кораблики бесплатно) обеспечить поддержку и, скажем, замену кораблика на другой такой же, если кораблик поломается, что вы должны прислушиваться к желанию людей и выпиливать те кораблики, которые хочется им (всё ещё бесплатно)?
К тому, что утверждение «в опенсорсе тоже нужна популяризация» неверно.
svr_91
И я не писал
А вы вырезаете? Я не знаю. А почему? Потому что, даже если и вырезаете, то на публике нигде не показываете. Зачем тогда проекты в OpenSource выкладываете?
Вы каждый день популяризируете Haskell/Idris :)
0xd34df00d
Лан.
Потому что создать репку на гитхабе сильно проще, чем выложить кораблик на публичное обозрение. Потому что я так могу продемонстрировать свои навыки (программиста, не аналитика) потенциальному работодателю. Потому что это такие бекапы, если хотите. Потому что так легче синхронизировать состояние разработки на разных машинах. Потому что могу. Да мало ли причин?
Ну и потому, что проект, возможно, будет кому-то полезным. Но это не значит, что я буду прикладывать какие-то специальные усилия для того, чтобы проект был кому-то полезным, или чтобы те, кому проект будет полезным, про него узнали.
В любом случае — неужто выкладывание проекта на гитхаб под опенсорс-лицензией наделяет меня некоторыми обязанностями и долженствованием по части продажи этого продукта в каком бы то ни было смысле? Не припомню этого в текстах лицензий или в ToS гитхаба.
При этом я не являюсь разработчиком ни того, ни другого. Ну и ещё чем больше людей будет пользоваться приятными мне языками программирования, тем лучше будет моя жизнь. Ну и ещё, чего таить, осознание того, какой я классный д'Артаньян, приятно щекочет нейроны.
svr_91
Я как раз утверждал обратное, что миллиарды пользователей не нужны
Приватные репы никто не отменял
Это и называется продажа
Далеко не всегда продажа про пользу :)
А почему бы и нет?
Да никто и нигде не наделяет никакими обязонностями. В частности и по другим пунктам статьи. Но вы прицепились почемуто именно к этому
Не обязательно быть разработчиком, чтобы что-то продать
О. Дошли до того, что вы так отрицали
0xd34df00d
Ну, то есть, таки писали про них.
Зачем это утверждать, если тезис про миллиард пользователей никто не высказывает?
Я на гитхабе прмерно с декабря 2007-го, бесплатные приватные репы там стали доступны только несколько лет назад.
Это вообще никакого отношения к продаже продукта не имеет. Это продажа себя, если хотите.
А про что? Можете сформулировать, что такое продажа, только чтобы это не получилось всеобъемлющим определением?
А зачем? Вон, например, у меня есть мелкая библиотечка. Зачем мне прилагать целенаправленные усилия, чтобы про неё узнавали?
Давайте перечитаем исходный комментарий:
Во-первых, здесь утверждается о любом свободном ПО. Во-вторых, утверждается, что нужна документация, удобство использования и поддержка. Так что нет, наделяют.
Вы снова путаете квантор существования с квантором всеобщности.
Здравствуйте, это точно канал програмистов?
svr_91
Я думал, вы подразумеваете миллиард пользователей, когда говорите "от большего количества пользователей увеличится количество денег у меня на счету" или "Ну и ещё чем больше людей будет пользоваться приятными мне языками программирования". Ну если нет, так нет
Не знаю насчет гитхаба, но на томже битбакете бесплатные приватные репы можно было завести уже давно. Не знаю, с какого года, но сильно раньше, чем на гитхаб.
Тем не менее. Какая разница, что продается. В опенсурс тоже не продукт продается (обычно, обычно, давайте не цепляться за излишнее обобщение, ок?) а поддержка например
Ну ок, не до конца сформулировал, грешен. Я отвечал на этот тезис "чтобы проект был кому-то полезным" и имел в виду, что продажа не всегда приносит пользу покупателю, что ж поделаешь. Продавцу как правило да, пользу приносит.
Ваше право. Хотите, прилагайте, хотите нет. Странно в одной фразе утверждать, что ваши наработки полезны, а в другой, что нет. Ну не полезны, значит не продвигайте.
"Переходя дорогу, посмотрите сначало налево, потом направо". Прям на любой дороге? И на дороге с односторонним движением? И на заброшенной дороге? И на трапинке? И на детской железной дороге тоже? Кто эти правила составлял? Расстрелять всех, смущают только простой народ
Только ситхи всё возводят в абсолют. Вот любите вы придумывать излишние обобщения на ровном месте и тутже их опровергать. Вот вообще неспортивное поведение. Даже в науке или математики нет цели опровергнуть выдуманное утверждение, а есть цель докопаться до истины. Не представляю, как вы наукой занимаетесь
К томуже заметил противоречие
Тоесть вы желаете автору яп своей участи?
0xd34df00d
А вам оппонент точно нужен для дискуссий? :]
Нет, серьёзно, в моём опыте геморрой от наличия пользователей начинается даже не с наличия пользователей, а с попыток их завести. Ну там, постишь что-то на лор или опеннет — начинается «нинужно», «лучше присоединись к $otherprojectname», etc. Зачем это всё?
Если я правильно помню свой 2007-й, то битбакет в окрестности того времени был mercurial-only, и смысла на него переходить с гитом не было.
Большая: изначальный комментарий явно указывал, что именно надо продавать (документацию, удобство использования, поддержку). Здесь я не продаю ничего из этого — я просто пишу интересный мне код.
Более того, моя привлекательность для работодателя не зависит от количества пользователей (и скорее даже антикоррелирует с ним до любого разумного достижимого уровня популярности). Просто потому, что количество ресурсов ограничено, и я могу потратить час на то, чтобы исследовать, где кнопочку будет удобнее разместить и какие кнопочки хотят пользователи, а могу — на то, чтобы наваять какую-нибудь наркоманию на темплейтах. Практика показывает, что на тех работах, которые мне интересны, демонстрация навыков второго рода полезнее.
Тут главное не сделать случайно вывод, что любое принесение пользы делает вас продавцом, что-то продающим.
Вы различаете «мои наработки полезны» и «я могу надеяться, что мои наработки могут оказаться кому-то полезны»?
Да какой абсолют? Вы пытаетесь доказать общий случай частным примером, причём тут абсолюты?
Я просто прямо интерпретирую то, что пишут люди, без додумываний. Например, можно было бы написать «в опенсорсе тоже могут оказаться полезными навыки продажи, если вам важно, какое количество людей пользуется вашим продуктом» — согласитесь, это далеко не то же самое, что и (условно сокращённое) «в опенсорсе тоже нужны навыки продажи»?
Математика — она, если что, целиком про доказательства или опровержения выдуманных утверждений (что в классической логике с аксиомой исключённого третьего вообще изоморфно). И формулировки в математике очень, очень важны.
Ну идрисом всё равно никто никогда не будет пользоваться, а у хаскеля уже давно нет какого-то конкретного одного автора (или выраженной группы авторов), у которых бы болело сердце за это вот всё.
Плюс, тот же идрис пилится людьми на зарплате (пусть нередко и аспирантской).
Плюс, возможно, это я такой чувствительный со своими клетками, а им всем там норм, хз. Я не умею в эмоции и эмпатию.
svr_91
Неправильно. Уже обсуждали, что количество пользователей не сильно важно. Можно например продовать продукт компаниям (да в большинстве случаев я полагаю в опенсурсе и продается компаниям).
Переформулируйте.
Давайте-давайте, интересно, как у вас получится правильно
0xd34df00d
Что неправильно? Там написано «если», а не «только если». Стрелочка импликации на самом деле не поворачивается.
Формальнее, A = { вам важно, какое количество людей пользуется вашим продуктом, и вы испытываете приятные чувства, когда это количество растёт, а не падает }.
B = { вам могут быть полезны навыки продажи }.
Я формулирую утверждение A ⇒ B. Вы зачем-то в ответ опровергаете утверждение B ⇒ A, приводя пример, когда ¬A ∧ B (что действительно несовместно с B ⇒ A, по крайней мере, в обычной двузначной логике).
svr_91
Как и всегда, ваш ответ абсолютно точен и абсолютно бесполезен. Вы хоть сами поняли, что хотели этим ответом сказать? Почему тогда не придумать миллиард подобных ответов?
Если вы хотите, чтобы ваш проект отправился в космос, вам возможно потребуются навыки продажи.
Если вы хотите, чтобы ваш проект не съел кракен, вам возможно потребуются навыки продажи.
Если вы хотите, чтобы ваш проект не продавался, вам возможно потребуются навыки продажи.
Что тут останавливаться-то?
svr_91
Да и вообще, речь была не о вас, а об опенсорсе в целом.
0xd34df00d
Это неважно. Человек утверждает что-то об опенсорсе в целом, и мне интересно, как это транслируется на меня, как на частично участвующего во всяких опенсорс-действиях. А что речь заходит о субъективщине — ну так извините, вся эта тема исключительно о субъективщине и эмоциях.
svr_91
Тут, как в известном анекдоте, ваш ответ абсолютно точен и абсолютно бесполезен. Ну очень странно отрицать, что opensource проекты имеют продажников в том числе. И да, всегда можно найти контрпример, но ради чего? Можно например найти человека, который генерирует смишьные надписи в таблице активности на гитхабе. Он тоже будет опенсурс разработчиком?
0xd34df00d
Я отрицаю, что опенсорс-проектам нужны продажники без всяких дополнительных условий.
Опровергать это через абсурдность генераторов надписей — ну такое.
svr_91
Не нужны. Точно также, как программистам не нужно учиться новому, тестировать код, писать понятную документацию, уточнять неясные требования. Вполне есть программисты, которые спокойно живут и без этого
0xd34df00d
Отличная аналогия! А теперь попробуйте в каком-нибудь другом треде высказать «программисты должны постоянно учиться новому» или, не знаю, «программист обязан иметь личный опенсорс». Фрейминг, конечно, будет играть роль, но я утверждаю, что существуют разумные фрейминги, в которых вам куда-нибудь наминусят.
svr_91
Дык потомучто и правда не должны
sergeypachkov
необязательно - большое число пользователей скачавших ваш софт с "torrents.РУ" не принесет денег, зато принесет проблемы с отзывами на плохую работу и ошибки.
большое число пользователей - потребует затраты на комманду поддержки, и реакцию на заявки - затраты на устранение проблем
Они ещё откажутся покупать новую версию ПО, так как предыдущая их вполне устраивает )))
alemiks
поздравляю, вы пока не переросли пп 2, 3 и 9. С опытом придёт (но это не точно)
0xd34df00d
Применяете ли вы эти пункты к любому вашему хобби?
alemiks
не очень понял, как это связано с хобби. Хобби — это нужность дл себя. В разработке ПО обычно не ограничивают ЦА «собой», чуть-чуть пошире выборка
0xd34df00d
Если вы посмотрите комментарий, на который я отвечал, то он описывал продажу в случае свободного ПО. Значительная часть свободного ПО делается энтузиастами в личное время в качестве хобби.
tmin10
Смотря какие цели создания СПО, конечно же. Лично мне приятно, когда плодами моих трудов пользуются и указывают на ошибки, это помогает развиваться дальше. Хотя тут есть обратная сторона медали: чем больше комьюнити, тем больше в нём будет токсичных личностей, который будут давать негативные эмоции.
0xd34df00d
Ну вот а мне просто нравится писать код и решать разные задачи.
Когда-то давно мне тоже что-то там хотелось про пользование трудов, про то, чтобы моё ПО было полезным, и так далее, но с опытом (вот прям как писал комментатор выше) я понял, что это всё ерунда, так как это гордыня, и это слишком сильно убивает мои нервные клетки. Если хотите, минусы от токсичного коммьюнити перевесили плюсы от… а не знаю, какие плюсы, я не помню их.
mvv-rus
Вы уверены?
К примеру, у Линуса Торвальдса жизнь явно стала лучше, именно от того что очень большое количество пользователей пользуется первоначально разработанным им программой: он занимается своим любимым (ну, разве что, оно ему успело надоесть) делом и явно не испытывает недостатка в деньгах.
За все остальное не скажу, но внешне он явно в шоколаде.
PS Есть очень интересная тема — финансирование разработки ПО: как показывает практика, в нашей реальности она не исчерпывается банальной продажей программного продукта AKA коммерческое ПО.
0xd34df00d
Ну так сколько этих Линусов Торвальдсов, а сколько — обычных людей, которые просто что-то там по вечерам и выходным пописывают в опенсорс?
Вы о донатах или о чём-то ещё?
mvv-rus
Показываю, почему ваше возражение не годится, а для этого немного переформулирую по аналогии:
сколько этих Биллов Гейтсов, а сколько — обычных владельцев мелких фирмочек, делающих коммерческое ПО или, там, разработчиков shareware?
То есть, на слуху у нас, конечно, только нечто масштабное, но этим индустрия отнюдь не ограничивается. Я, вот, к примеру лично знаю человека, который зарабатывал деньги на свободном ПО, как минимум, ещё с 1998 года: тогда он делал интернет-проекты для небольшой фирмы, где я работал, ну а сечас дорос до руководителя вполне заметной в России фирмы, которая как раз на свободном ПО зарабатывает.
Не только. Я же не зря писал, что тема очень интересная.
Если вкратце (статью я писать-то не готов): механизмов финансирования разработки ПО много. Это могут быть и пожертвования частных лиц, и всякие государственные и полугосударственные фонды, и производители оборудования (типа IBM — именно они лет 15-20 назад очень сильно поддерживали Linux), и поставщики интернет(они же — облачные)-услуг, использующие ПО. Ну и всегда остаются производители ПО заказного или полузаказного (требующего значительной доработки под конкрретного заказчика) — без них крупный (а в особых случаях — и не крупный) бизнес не может удовлетворить свои специфические потребности.
Более того, со временем господствующий механизм меняется. В 50-70-е годы им было перераспределение прибылей производителей оборудования — IBM AKA Big Blue и другие, — для которых ПО для их оборудования было побочным продуктом, повышающим ценность их основного продукта. В 80-00-е этим механизмом стала продажа отчуждаемого программного продукта — в чем особо преуспела всем известная Microsoft. А в наше время значительную роль в финансировании ПО играют как раз поставщики услуг через Интернет.
Как-то так.
0xd34df00d
Вы пытаетесь доказать, что на опенсорсе зарабатывать можно, в ответ на утверждение, что опенсорс продавать (в каком бы то ни было смысле) не обязательно. Вы уверены, что это релевантно?
mvv-rus
Да. Потому что "продавать" (здесь точнее, наверное — "продвигать") и "зарабатывать" не то, чтобы совсем сопадают, но, по крайней мере, довольно сильно коррелируют.
Но вообще-то неплохо было бы ещё и определиться, что имеется в виду под словом пользователи
0xd34df00d
Тут акцент не на «зарабатывать vs продавать», а на том, что наличие примеров, показывающих, что на опенсорсе можно зарабатывать, не означает, что на опенсорсе нужно зарабатывать.
mvv-rus
Совершенно верно!
PS У нас в повестке ещё остались какие-нибудь спорные вопросы?
svr_91
Вы сами попросили оппонента расскрыть вопрос заработка на ОС и почемуто удивились, когда он этот вопрос заработка раскрыл :)
Swiftarrow7
Хм, то есть хорошая документация, удобный интерфейс - это только при продаже надо делать? Забавно получается - хочешь продать пиши удобную документацию. Не хочешь продавать - пиши, что хочешь?
Как по мне - не продавать надо, а создавать стандарты, которые как раз буду людям объяснять как и почему лучше, а не как продать побольше. Тогда и не будет выбора между "красиво, удобно" и "эффективно, функционально". Возможно тогда будет решать не маркетинг, а качество, эффективность и набор возможностей. И возможно тогда не будет кучи бесполезного, однотипного софта, каждый выполняющий только ограниченый набор функций, причём не имеющий общих функций, или имеющий, но каждый решающий только часть из того, что может потребоваться пользователю =)
tmin10
Если проект для себя и ни с кем делиться с ним не намерян, то документация уже опциональна, а интерфейс можно сделать под себя, а не как всем удобно. А то потратишь кучу времени не на основной функционал (для чего проект), а для подгонки под некие стандатры качества, а оно и не надо никому.
Swiftarrow7
Так и? Это никак не рушет концепцию "хочешь продать - пили документацию и удобный интерфейс, не хочешь - не делай". Только для своего проекта глупо не делать документацию. Через год откроешь и нифига не помёшь!)
iaretedd
Простите, если я несколько раз невнимательно прочитал комментарий, на который Вы ответили, но, пожалуйста, укажите мне, где речь идет о свободном ПО?
На мой взгляд, мысль имеет право на жизнь.
iiopy4uk_mck
Я понял так, что речь идет о ПО вообще. Видимо как и многие люди.
Абсолютно уместно упомянуть, что в этом множестве есть еще свободное, причем все ПО построенное при моем участии из него и состояло. Утверждение сразу теряет всеобщность.
muove
Свободное ПО еще как продается. Это и системы на основе свободного ПО и услуги вокруг свободного ПО и идеалогия вокруг свободного ПО. Все продается. К сожалению 100500 статей о каком либо свободном продукте не появятся внезапно, кто то должен за это платить. За популяризацию, за поддержку, за человеко часы потраченные на его разоработку (я не говорю про маленькие ламповые утилиты). Посмотрите на RedHat, Hadoop, Spark и прочих. Вокруг всех них есть кто то, кто драйвит это ПО и делает на этом денгьги. Это не плохо с моей точки зрения. Просто еще один способ продаж.
PereslavlFoto
Существование Викисклада и Википедии убедительно опровергает ваши слова.
Kanut
В каком конкретно месте? Или это разве не на википедии висели баннеры с просьбой дать им денег?
PereslavlFoto
В том месте, где вы получили все права на использование этого контента, не уплатив никаких денег.
В том месте, где вам ничего не продали, а всё передали и разрешили по бесплатному договору.
Kanut
Каким образом это должно опровергать написанное выше? То для примера конкретно вот эту фразу:
Swiftarrow7
Хм, то есть, мне не может понравится продукт, или он не может просто решать поставленные задачи?
Увы, как мне кажется не всё продаётся! Я выбрал Линуксовую ось не из-за маркетинга, а потому что другая ось не предоставляет мне возможности, которые я хочу иметь. И мне не продавали линукс, а просто сказали, что в это системе возможно то, что мне нужно. И не рекламой =)
Так что приводить в пример СПО, в контексте "продажи", а значит цепляя понятие "маркетинг" - ну оч спорное суждение =)
Вот "окно" - да согласен, прям всё построенно на маркетинге. Да, согласен с автором статьи - если целимся не на пользователей - терям не только прибыль, но и публику. Будь линукс дружелюбным, как та же макось (на секундочку unix подобная система), будь у него маркетинг и экосистема - вы бы сидели на линукс и также рассуждали, про него. Но увы - этого вего нет у линукса и он просто решает задачи пользователя. Да, на нём тоже можно заработать, но за использование Линукса - кто-то платит? За использование FreeBSD - ничего не просят. Много людей знают о FreeBSD или OpenBSD? Хм, сомневаюсь, что в данном случае маркетинг их спасёт. Продавать то нечего =)
P.s. RedHat не был коммерческим первоначально и разрабатывался и хайпил за счёт сообщества, а не маркетинга. Уже после появления коммерческого продукта появилась свободная Fedora (которая не так популярна), и уже после они стали зарабатывать и хайпить. Думаю с остальными из списка была похожая ситуация. И, где TenserFlow?
Swiftarrow7
Если вам вдруг станет интересно - статья на хабре (https://habr.com/en/company/redhatrussia/blog/351170/) + можете почитать, что об этом пишут в сети =)
alemiks
соглашусь с комментатором выше, такие штуки, как документация, удобство использования, качество ПО, распространяются как на свободное бесплатное, так и закрытое платное. Если пользоваться им неудобно, то люди будут переходить на альтернативы. Личный пример: GIMP плох, купил Pixelmator; VirtualBox плох, купил Parallels; LibreOffice плох, купил MS Office. Хотя, бывают и краевые случаи: участвовал в проекте, где использовался redmine (он плох, да) на сервере, который стоит в подвале у одного из коллег. Всё из-за экономии. Я за всех оплачивать жиру не готов, поэтому пришлось
caes
В обратную сторону это работает точно так же. Нельзя продать отсутствующий продукт. Пограничные случаи типа мошенничества или инвестиции в расчёт не берём. Речь про здесь и сейчас. И даже более того, знания маркетинга не стоят ровным счётом ничего при проектировании сверхтяжёлой ракеты.
bak
Продать несуществующий продукт можно, называется "предзаказ". И первые партии новых продуктов зачастую именно так и продаются.
А вот технологически совершенный существующий продукт который никому не нужен - продать действительно не выйдет, сколько не пытайся.
caes
Специально же написал про пограничные случаи. facepalm.
vsh797
МБ потому что всю работу по маркетингу уже кто-то проделал и выкатил ее результаты в виде технических требований и бюджетов?
caes
Техтребования - это маркетинг? Тогда уменьшение - отрицательный рост. Даже ответить нечего на такую логику.
vsh797
Ок, а откуда вы их тогда возьмете? Ориентироваться-то на заказчика/клиента надо. Того, кто деньги в общем будет платить. Да, можно предположить, что на рынке есть только один потенциальный заказчик на разработку сверхтяжелой ракеты в лице родного государства. Но за доставку грузов на орбиту платить уже готовы многие. И их мнение, а также конкурирующие предложения при проектировании неплохо бы учитывать.
Swiftarrow7
Привет Гагарину передайте и маркетингу в СССР, и гонке вооружения. Ага маркетинг. Конечно, полететь в космос - это маркетинг. Чёт интересно Америка именно поэтому свою космическую программу создала? Ракеты Маска поэтому многоразовые? Потому что пиарится надо или потому что так выгодней? Мы теперь маркетингом будем ТТХ обосновывать? Лол.
Чес слово, вот что что, а ракета не маркетинг. Маркетинг - это "Наша ракета летает быстрее других, в ней есть печеньки". Я думаю когда Гагарин полетел первый раз в космос его не печеньем и комфортом и функциональностью затащили, а тем, что есть идея, есть желание человека покарить и увидеть космос, первому там оказаться (вот тут да маркетинг). Что теперь будем делать сотню разных ракет и доказывать друг другу у кого комфортней? Или просто опишем общий стандарт и позволим по-разному конфигурировать? Мне кажется второе куда логичней первого, и имеет как минимум большую эффективность и пользу для общеста, нежели пилить сотню ракет и каждую всем вокруг презентовать как лучший вариант. Конкуренция не есть хорошо, хорошо - это когда сделано эффективно, красиво и удобно - или проще говоря оптимально.
vsh797
Вы зря так обижаетесь на маркетинг. Печеньки для него — это лишь частный случай продвижения товара. И то скорее на b2c рынке.
А вообще маркетинг — это процесс сбора информации о рынке (кто наш покупатель, что ему нужно, те же конкуренты), а затем процесс продвижения товара (в случае b2b какие-нибудь встречи, выставки, информационные буклеты, рассрочка и прочие спецпредложения). И даже самые крупные производители оборудования нисколько этого не стесняются. Можете хоть на авиаотрасль посмотреть. Да и у того же Маска пиара в деятельности хоть отбавляй. В любом его бизнесе, кстати. Не говоря уж о том, что технические решения вроде используемых материалов и возвратности ориентированы как раз на определенные сегменты рынка полетов на орбиту.
bjornd
Да собственно второй пункт как раз про это.
navferty
Отнюдь. Можно создать идеально подходящий продукт, но люди будут продолжать пользоваться менее удобным, но привычным, для решения этой же проблемы - просто потому что они не знают про Ваш продукт, и сарафанное радио может не спасти. Нужно уметь рассказать людям об этом продукте, так чтобы они услышали и захотели попробовать.
Swiftarrow7
Хм, то есть идеально подходящий продукт надо тоже продавать? Тогда не идеальный он. Если просто описание функций, которые работают идеально, интерфейса, который идеальный и невероятно удобный, и производительность, которую непривзащёл никто другой так как она у нас идеальная - не хватает? Это тогда что нужно сделать чтобы пользователь захотел его использовать? Машину каждому дарить?
Мне кажется покажи свою программу в сравнение с другими, и не обязательно только на киллер фичах - и народ потянется. Не рекламой всё таки надо а в целом выбором того, что решает твою проблему.
navferty
Вот Вы сами говорите - программу нужно показать. Иначе люди просто не узнают про неё. Сарафанное радио - это хороший способ распространения, бесплатный, надёжный... но очень медленный.
Можно сделать идеальный продукт, сделать идеальное описание, выложить его на гитхабе - но никто о нём не узнает. Пусть он идеально решает какую-то проблему, но люди привыкли использовать для её решения условный Excel - и они продолжат им пользоваться. Возможно, первый раз с ней столкнувшись, они и попробуют погуглить варианты решения. Но они не будут это делать каждый раз, снова решая эту проблему.
Не обязательно давать платную рекламу, может быть, достаточно будет написать статью на хабр, с описанием нового чудо-решения.
SergeAx Автор
Здесь, я считаю, должно быть разделение труда. Инженеры не должны заниматься маркетингом или продажами, для этого должны быть специальные компетентные люди, к мнению которых надо прислушиваться. См. также п.п. 2 и 3.
Dmitrsha01
Продажники это и есть трансформеры акул в динозавров. Какие мат.методы системного анализа не содержатся в библиотеках Фортрана? В какие резолюции принципиально нельзя учить базу знаний ЯУ СУБД Пролог? Подозреваю, что без маркетологов убедительных ответов на оба вопроса не будет))
Swiftarrow7
Много маркетологов знают Фортран и используют его в своей работе? Многих маркетологов вы знаете которые используют Фортран для решения повседневных задач? Мне кажется если мы будет инструменты рекламировать разработчикам - то это уже не разработчики, а какие-то работники уровня секретарей, которые сморят тупо на статистику и принимают решения. Когда это сфера IT стала смотреть на маркетинговую состовляющую инструмента, а не на то, что этот самый инструмент способен решить? Когда это инструменты стал важнее решения задачи оптимальным способом, а не "Нет смузи на логотипе, поэтому не буду использовать". Забавно получается, не правда ли?
Gorthauer87
Достаточно просто оценить, насколько вообще у компании хорошо идут дела с этим делом, для этого особых знаний не надо по маркетингу.
ysirotenko
Во втором пункте об этом упоминалось
kibizoidus
"Нужен" и "продался" / "стал популярным" - разные вещи. Для первого - ничего не нужно, он просто нужен или нет по факту существования, для второго нужно тонны упорного труда и наработки по линии маркетинга, как для OSS, так и для проприетарного софта.
SNNikitin
Это пп. 2 и 5 в сумме и чуть под другим углом ;)
kibizoidus
Нет и нет. Продукт может быть нужен, но о нем никто не знает и "когда-нибудь он выстрелит" здесь не работает. Пятый же пункт - он о целях, а не о успешности проекта. Банальный пример - софт интерактивного управления ракетами, написанный дома, и успешно протестированный на клубных моделях, но после - закинутый на полку. Работает? - Да. Цели добился? - Да. Нужен? - Не известно (но вероятнее всего - очень). Заброшен и не развивается? Да. Весь букет. И таких проектов у каждого увлеченного программиста - есть о чем поговорить.
SNNikitin
А зачем продавать-то, если продукт, например, внутренний или для специфической аудитории? Или - вообще бесплатный?
Деньги - не единственная ценность для бизнеса и разработчика
Так что - да и да :)
kibizoidus
"Продать" != "Деньги". Откуда такая жесткая фиксация на том, что "продать" - это сразу деньги?
Нет, продать - это значит убедить человеков пользоваться. Именно этим и занимается маркетинг софтварного продукта. А что у вас там есть какие-то возвышенные цели или маленькие аудитории - уже вторично. Если проект не развивается, у него нет пользователей, нет новых возможностей апдейтов и реакции на изменения снаружи - он мертв. Даже если выполняет свои цели здесь и сейчас.
Я об этом писал, а не о ваших деньгах. Смотрите, пожалуйста, дальше кончика своего носа и своих меркантильных интересов.
Dixi.
SNNikitin
Вы бы умерили пыл и были бы поосторожнее с формулировками - вас заносит в хамство.
Далеко не всегда надо убеждать пользоваться - иногда выбор делается административным путем или в силу отсутствия альтернатив.
И да - проект может не развиваться и, при этом, быть живее всех живых - мир сложнее и не такой черно-белый, как вы пытаетесь представить ;)
И - снова про хамство. Ваша пылкость и приверженность некоей идее его ни разу не оправдывает.
Sapienti sat.
kibizoidus
Давайте не переходить на личности. Я вам не хамил, но в том числе предложил смотреть дальше и знакомиться с темой обсуждения глубже. Потому как она действительно намного глубже и обширнее чем "я продал боссу Х строк кода". Не понимаю, почему вы восприняли это, как хамтво, но все же - прошу прощения.
SNNikitin
Это - хамство, если вы не знали :)
>"я продал боссу Х строк кода"
Ничего похожего я не говорил ;)
>прошу прощения
Принимается! :)
DeathSAAD
Пример. Ваша целевая аудитория: люди с ограниченным зрением (думается на таком примере понятнее всего будет, надеюсь)
Теперь расскажите, насколько разработчику должно быть всё равно и не его дело знать о целевой аудитории и о том как продукт будет продаваться (с технической точки зрения, а не маркетинговой).
А то мне рисуется картина, как пандусы у нас делают, по которым если спустишься - еще больше инвалидом станешь. Не, ну а что, там же строители, не их забота думать о целевой аудитории и том, как их продукт использоваться будет.
И конечно же, если для вас программист - это тот кто код набирает, то вы безусловно правы в своих суждения. Однако для меня программист - это инженер, и его главный навык - умение анализировать и находить решение.
SergeAx Автор
Смотрите, в нормальном мире есть такой специальный человек, менеджер продукта, который 1) знает как надо 2) может записать это знание в виде спецификации 3) может найти общий язык с инженером, совместно с ним эту спецификацию привести к виду, пригодному к техническому воплощению.
Это задача менеджера продукта - влезть в шкуру пользователя и понять, какие у него потребности и пути их удовлетворения.
DeathSAAD
Смотрите, в нормальном мире есть средний и малый бизнес и команды из двух-трех человек.
И далее, чтобы ваш "специальный специалист" мог найти общий язык с инженером, то этот специалист либо должен быть сам инженером, либо инженер иметь немного знаний из области "специального специалиста".
Также я нигде не писал, что информацию должен собирать программист - у него своя работа, но чтобы эту информацию воспринять и воспринять максимально правильно - знания области, из которой приходит информация - дает огромную фору.
SergeAx Автор
А как вы определили, что это ботовод? Я просто думал, одобрять или не одобрять пустой коммент, и представил, что это живой человек, и что ему, наверное, странно, почему его за approve-wall вдруг отправили (и тут есть ещё комменты от очевидно живых людей, которым был нужен аппрув). Решил, что одобрить будет меньшим злом.
DeathSAAD
Вообще немного сбоку есть. Например, понимание кто твой покупатель дает возможность лучше продумать этап сборки и распространения приложения. А этот этап уже может быть технический и в том числе частью разработки.
Знание маркетинга является той сферой, которую должен понимать разработчик, если его ПО работает в сфере маркетинга. Аналогично тому, как разработчик в сфере медицины имеет знания из области медицины, в сфере банкинга - знания по банкингу и т.д.
В любом случае небольшие знания из смежной области еще никому не вредили и зачастую позволяют делать свою работу более качественно и эффективно.
repeat
Всё смешали. Речь не о маркетинге больше. Программисту хорошо бы задумываться кто и как будет пользоваться ПО, но ни как о том, как его продать.
kibizoidus
В первом камменте я попытался чуть более развернуть свою мысль, где стоит искать эти знания, и меня заклевали труЪ-инженегры и погромисты, которые "Just fuckin code" и увидели слово "продажи".. Люто плюсую ваш комментарий.
0xd34df00d
Именно поэтому хорошо писать библиотеки, которыми просто будут пользоваться другие программисты.
justboris
Вы, наверное, из тех разработчиков, которые тесты тоже не пишут, потому что это задача QA? А задачи программистов – исключительно писать код и больше ничего?