×
Фото Должен ли программист быть нацелен на гешефт?

Должен ли программист быть нацелен на гешефт?

tl;dr: Как бы да, но нет.

tl;dr: Как бы да, но нет.

За время, как я стал интересоваться, как работает бизнес, а также историями успеха и неуспеха различных начинаний, я познакомился с большим количеством людей и услышал много интересных историй.

Были прекрасные истории о том, как ребята начали делать какой-то стартап, но не смогли додавить по комплектующим/продажам и т.д. А через год появлялась аналогичная система, захватившая тот микрорынок и удовлетворившая ту же потребность у той же целевой аудитории и тем же способом. То есть то же самое, но win!

Не менее интересны истории о том как для создания маленькой фигни люди нанимали большой штат неспециалистов, делали полный треш в плане дизайна, юзабилити, тем более кода, но, чёрт возьми, выходили в плюс! Это, конечно, редкость, но есть и такое.

В этом моменте возникает вопрос: так чему же уделять внимание — получению прибыли, или же нормальной проработке продукта?

«Просто бизнес, ничего личного» — само собой, любой бизнес создаётся для извлечения прибыли. Посему — да, программист должен думать о том, как продукт, который он разрабатывает, сможет привлечь больше денег.

«Но есть нюанс». К сожалению, внимание человека ограничено. Были какие-то исследования, что 7 контекстов — среднее количество проблем, о которых может думать человек. Выкиньте из этого быт, себя, хобби и ещё что-нибудь и останется крайне мало — штуки 2-3. Ах да, ещё надо коту еду купить на обратном пути, да и шампунь закончился… Короче, 1.

А теперь простой пример: мы поняли, что людям не хватает жилья.

Собственник постучал в калькулятор — прикинул среднюю стоимость по рынку, размер рынка и вероятный спрос.

Сбросил продажникам задание пробить: что там по рынкам сбыта, какой реальный ценник и прочее.

Кинул юристам пробить, где и как можно получить разрешение на строительство, как всё это сделать жилым, да к комунальщикам присосаться.

Дал задание архитектору: всё это распланировать, чтобы главный городской архитектор это принял, чтобы планировки были вменяемыми, чтобы уместиться в участок и бюджет.

И стоит рабочий на стройке. И думает он о благостном:

  • какова будет средняя стоимость и маржа,
  • каков рынок, цена предложения, лида и прочего маркетинга,
  • где бы можно было разместить объявления и как своё предложение продвинуть;
  • что главный гор. архитектор обязательно придерётся вот к этому и этому;
  • что комунальщики козлы и обязательно дадут гадкую инфраструктуру;
  • что архитектор сделал слишком далеко лифт от парадной…

…только кирпич не кладётся, да цемент не замешивается…

И думает он о многом и голова его тяжела от дум его… Только думает он обо всём, да ничего не делается. Потому что он на своём этапе не подумал о том, чтобы замешать цемент правильно, кирпич проверить, чтобы всё это положить и прочее.

В общем, исполнительство и следование стандартам, срокам также важно, как и понимание смежных областей. Поэтому хорошо, когда каждый представляет общую цель, понимает смежные работы и хорошо исполняет свою работу. Аминь.

Комментарии

Фото
94 дня назад Valerii_Palych

Инженер? Нет... Врач? Нет... Педагог? Тоже нет... Программирование - ремесло, программист - ремесленник. Из этого надо и исходить.

Фото
94 дня назад 1337 900913

Интересный вопрос. Я и сам долгое время считал программирование ремеслом. Всё ведь сходится: разной руки ребята пишут программы, по большей части ценность этих программ в том, что они делают, а не в истории появления или личности автора (в сравнении с искусством). Однако, в последнее время я думаю, что стоит взглянуть под другим ракурсом: программирование - это инструмент! Как молоток или перо писателя. В зависимости от навыка и задач он может как подходить, так и быть вредным. Разный навык использования этого инструмента определяет качество результата. Когда мы говорим, что программирование - это ремесло/искусство, мы говорим о процессе. Говорить о процессе можно много (да и говорят много, но не в этом смысл). Когда мы говорим, что программирование - это инструмент, мы нацелены на результат. В последнее время я всё больше за результат, а не за процесс.

Фото
93 дня назад Valerii_Palych

Все проще... В процессе работы, талантливый ремесленник, оттачивая мастерство, используя зачастую собственный инструментарий, становится мастером, то-бишь маэстро. Маэстро - мастер! Блоху подковал кузнец Левша...
P.S. Смотровая щель для комментария, пожалуй, требует вмешательства маэстро Георгия. ))

Фото
93 дня назад Гоша Бажуков

Доброго дня! О чём речь? Какая "смотровая щель"? Или про то, что поле ввода увеличить?

Фото
93 дня назад Valerii_Palych

Здравия желаю! Да, именно так... ИМХО.

Фото
92 дня назад 1337 900913

Сделано. Просто, но надеемся, удобно.

Фото
92 дня назад Valerii_Palych

Вот! Браво Маэстро!
Эффект танковой смотровой щели устранен. :-)

Фото 10 хороших примеров работы в Linux, FreeBSD и прочих Unix. Часть 8 — подсчёт с grep
Предыдущая запись:
10 хороших примеров работы в Linux, FreeBSD и прочих Unix. Часть 8 — подсчёт с grep
Фото Продолжаем эксперимент "Scrum чужими руками"
Следующая запись:
Продолжаем эксперимент "Scrum чужими руками"

Интересное на «Цифре»

Фото 5 причин не исправлять "ошибки"
5 причин не исправлять "ошибки"
Сразу оговорюсь, речь пойдёт не о критических ошибках. Если ваш сервис лежит бездыханный, то конечно — ноги в руки и фиксить.
"Чайка-менеджмент". Опасности и злоумышленники
Не так давно мы рассмотрели анти-паттерн “Чайка-менеджмент”, однако, совсем забыли рассмотреть опасности для такого менеджера
Фото «Методологическое безумие» и «Scrum»
«Методологическое безумие» и «Scrum»
Пока в Москве повальное увлечение методологией “скрам” меняется на “бирюзу”, в регионах так и продолжают внедрять “скрам”. Оба эти увлечения обычно не приводят ни к чему хорошему. В конце концов всё приходит к “у нас скрам, но не совсем” или “скрам — говно”
Противление методологиям как методология
Забавное нынче время. Попы освящают дата-центры, детям преподаётся креационизм, а в командах разработки появилось новое обзывательство: “теоретик”