Проекты бывают разные. Некоторые можно сделать за два дня, некоторые за месяц, некоторые длятся годами. Именно про последние хотел написать эту заметку.

Дело в том, что общаясь в среде различных программистов с завидной периодичность наблюдаю следующую сцену. Один разработчик рассказывает и показывает итоги своей работы другим программистам в надежде получить отзыв вроде: “Ну ты крууууут!“, в ответ же он получает не возгласы восхищения и аплодисменты, а вопрос: “На что именно было потрачено столько времени? На ЭТО? Что тут такого делать, почему так долго?“. После этой фразы начинаются жаркие споры, обиды, непонимание и обвинения в некомпетентности друг друга.

Хорошо когда такие беседы проходят в дружеской программисткой атмосфере. Гораздо сложнее, когда выяснение отношений происходит на другом уровне. Например, когда одна команда пытается подрезать заказ у другой, убеждая клиента в том, что если бы обратились к ним, то они дескать сделали бы все гораздо быстрее и без затягивания сроков. Что принятые решения изначально были нерациональными и т.д.

Более того, сами программисты спустя годы, оборачиваясь назад начинают думать: “Я потратил на это три/пять/семь лет своей жизни? Почему?! Как ЭТО заняло столько времени?”

Одной из причин, на мой взгляд, является не совсем точное представление о том, как оценивается сложность проекта. Для многих это прямая из точки А в точку B.
Пред глазами предстает следующая картинка.

На самом деле, это идеальная картина. В жизни разработка сложного проекта сопровождается решением многих неучтенных проблем. Возникают “развилки” на которых нужно принимать решение куда двигаться дальше. Это могут быть решения высокого уровня, такие как выбор языка (java, c#, python или всё вместе) или способ хранения данных (mysql, oracle, berkley db, mongodb, hazelcast или все вместе), так и более низкого уровня – какой веб-фреймворк выбрать (ext или gwt, или может быть JSF 2 и т.д.), прикрутить velocity или обойтись стандартными средствами для работы со строками, начать использовать более популярный graddle или остаться на maven-е (или даже ant-e), использовать AnglularJS или не стоит.

Таких “точек бифуркации”  в большом проекте может быть несколько десятков или даже сотен. При этом важно понимать, что все могут ошибаться и иногда приходится возвращаться на исходную позицию, менять стратегию, платформу (или как говорят программисты “переписать половину кода”). Кроме этого цель из точки B может передвинуться в точку B’ и в результате некоторые принятые решения уже могут оказаться неподходящими.
Другими словами лучше описывает ситуацию следующая картина.

В итоге, полученное “дерево решений” получается довольно ветвистым, а его “построение” делается методом “разведки боем” и занимает уйму времени. При этом, когда человек уже находится в конечной точке B и если он не страдает потерей памяти, то скорее всего повторить этот путь ему будет намного проще. Он уже знает как добраться к цели, по каким именно дорогам идти и на каком перекрестке свернуть.

Конечно более сложный случай, когда нет хороших проторенных “дорог”. Например, если это принципиально новая разработка. В таком случаях утверждение “Что он тут такого делает уже N-цатый год?“, звучит аналогично претензии к Колумбу: “Что тут такого? Здесь и ежу понятно, что нужно просто плыть на запад и попадешь в Америку“. Сегодня это кажется очевидным, а тогда найти средства на подобную авантюру было не так уж и просто.  Опять-таки в итоге Колумб все-таки ошибся где-то в три с половиной раза (почти на Пи), ведь изначально он хотел попасть в Индию, а она намного дальше…

Возвращаясь в наши дни, к теме этой заметки, хотел подвести небольшое резюме.

• Чтобы оценить сложность проекта нужно проделать большую работу (см. картинку с деревом решений). Не стоит прогибаться, когда заказчик требует выдать ему оценку сложности какого-то нового проекта в человеко-часах, суть которого вам изложили только что на словах в трех предложениях за чашечкой кофе. Реальная цена такой оценки наверное будет меньше стоимости выпитой вами чашки кофе.
• Не стоит удивляться и сильно корить себя за количество потраченного времени. Во-первых в жизни часто сложности забываются, поэтому возникает кажущееся ощущение легкости пройденного пути, а во-вторых задним умом мы все гении.
• Желательно искать хорошего “проводника”, у которого был опыт работы если не в аналогичных, то хотя бы в похожих проектах. Естественно, что каждый проект в чем-то уникален, но возможно его интуиция и опыт позволит частично избежать попадания в тупиковые ситуации.

P.S. В качестве иллюстрации нарисовал дерево, на развилках которого выбирается один вариант и подсвечивается красным цветом. При нажатии мышкой на дерево, оно случайным образом перестраивается.
Приятного просмотра!

P.P.S. Дерево прорисовывается с помощью языка программирования processing. Собственно экспериментами с ним, а также arduino и raspberry pi сейчас посвящены воркшопы, которые мы проводим вместо проводимых ранее Scala-тусовок.

Так получилось, что я знаком со многими программистами, которые работают в крупных (и не очень) софтверных компаниях в качестве наемных сотрудников, т.е. на окладе. На сегодняшний день Москве можно наблюдать два явления:
1. Дефицит квалифицированных кадров.
2. Кризис самореализации. Много ИТ специалистов в прошлом учились в лучших высших учебных заведениях России, но текущая их работы не в полной мере позволяет им реализовать свой потенциал. Одни мирятся с таким положением дел, у других возникает желание “изменить судьбу”, открыть свое дело, начать стартап, освободиться от “офисного рабства”.

Как следствие они начинают карьеру молодого предпринимателя, пытаясь начать самостоятельные проекты, искать заказы на разработку ПО. При этом у многих сохраняются наивные представления о том, как продавать свои услуги, на каких условиях работать с клиентом и самый главный вопрос возникающий у начинающего московского программиста-предприниматели – сколько стоят его услуги по созданию программного обеспечения. Для многих технически подкованных специалистов моего возраста в школьные годы не составляла особого труда решить примера вида:

Пример из сборника задач Сканави М.И. для поступающих ВТУЗы. В прошлом, те кто хотел поступить в ВУЗ могли решить такой пример не особо себя утруждаю, как мы шутили «спинным мозгом». Наверное сейчас с появлением ЕГЭ эпоха задач из Сканави уходит в прошлое.

С другой стороны, когда нужно сделать не намного более сложные арифметические и алгебраические операции, но вместо конкретных чисел будут стоять налоги, накладные расходы, человеко-часы, риски, объемы, сроки, скидки и другие составляющие, то это вызывает панику. Человек с высшим техническим образованием может потратить несколько дней или даже недель, чтобы найти грубые ошибок в своих вычислениях.
Другими словами, если речь идёт о готовом математическом выражении — всё просто, но если это якобы “бизнес” ситуация и нужно ответить на вопрос “за 100 000 сделаешь программу?” или “сколько будет стоит сделать мобильное приложение?”, то начинается тупёж. Например постоянно сталкиваюсь с людьми, которые путаются с процентами и не могут посчитать какую цену они должны указать заказчику, чтобы у них осталось 100 000 рублей после оплаты налога в 6% с дохода?
Казалось бы ответ очевиден – приблизительно 106 383 рубля, но даже в таком простом примере многие делают ошибки (считают 106 000) или вообще не учитывают налог в конечной стоимости («да ладно, пусть, чего мелочится, всего 6%»). Когда же нужно проделать более «сложные» вычисления, т.е. учесть в цене все затраты (часы на согласование проекта, тестирование, внедрение, отчисления в фонды, обслуживание счета в банке, расходы на аренду, обрудывание и другие расходы), то в итоге некоторые делают множество существенных арифметических, алгебраических и алгоритмических ошибок. Хотя на самом деле, здесь нет ничего сложного.

Ошибка 1.

Допустим существует некий абстрактный московский java-программист. Его зарплата 120 000 в месяц. Он решил, что начинает работать на себя. Какую стоимость человеко-часа выставлять заказчику? Берем зарплату и делим на среднее количество рабочих часов в месяц (допустим 164,17 часов). Получаем стоимость часа около 731 рубля.

Давайте приведем аналогию из сферы услуг. Я знаю фитнес-центр в котором годовой абонемент стоит 16 000 рублей. Это недорого для Москвы (даже скажем средний, бюджетный вариант). Фитнес открыт ежедневно, работает по 12 часов в день. Разделим 16 000 на количество часов в году (365 дней * 12 часов = 4 380 часов) и получим стоимость часа равную 3 рубля 65 копеек. Посчитав это, я решаю пойти и позаниматься 2 часа, т.к. по моим расчетам должен заплатить 7 руб 30 копеек. Вопрос, почему администрации фитнес-центра требует с меня за разовое посещение 500 руб?! Что за наглость?

  2 * (16 000 / (365 * 12)) = 7.30 != 500

Устраиваясь на работу, программист предоставляет свои услуги работодателю не на один месяц, а как правило по бессрочному договору, т.е. работать будет годами (хотя на обычно специалист меняет работодателя через 2-5 лет). Вы как бы “продаете” годовой абонемент своему работодателю — будут для вас задачи или нет, это уже не ваши проблемы. Фитнес-центр же не виноват, что кому-то лень тащить свое тело в зал и кто-то не приходит заниматься уже вторую неделю. Так и здесь, работодатель сам должен обеспечить вам фронт работы, а вы качественно программировать и получать каждый месяц зарплату. Если задач нет, то можно плевать в потолок или гонять танки, вашей вины в простое нет.
Другими словами, если вам предлагают проект на условиях: 2 миллиона рублей на 12 человеко-месяцев, деньги поступают каждый месяц, заказчик покупает вам необходимую для работы компьютерную технику, оплачивает интернет и аренду рабочего места, то можно говорить о том, что стоимость часа равна 731 рублей. Если это подработка на 60-100 часов, то о каких 731 рублей за час может идти речь? Вас же за 7 рублей в фитнес-клуб никто не пустит, хотя стоимость часа рассчитана по схожему принципу. Думаю для любого торговца на улице очевидна причина в разнице цены за килограмм картошки между покупкой ее вагонами и трех килограммов в розницу, но почему-то у программистов-предпринимателей работает “линейное” мышление в расчете цены.

Ошибка 2.

Есть такой бородатый анекдот:
Новый русский открыл фотосалон и дал объявление: “Приглашаю фотомодель для съемки. Оплата наличкой на месте. За час работы 20 тысяч баксов”.
Набежала куча моделей, отобрали одну, снимали с вечера и до ночи.
Приходит новый русский:
– Ну что, фотограф, сколько наснимал?
– Четыреста кадров.
– А выдержку ставил какую?
– 1/200 секунды.
– Ну ты, девка, в натуре, на две секунды всего лишь наработала, держи 12 баксов.
К чему я вспомнил этот старый анекдот из прошедшей эпохи? (далее…)

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

Статья про рок-банды, новое время и программирование.

Давно хотел провести аналогию между музыкой и программированием. Например команда разрабатывающая большие и сложные системы чем-то похожа на симфонический оркестр:

Вначале гениальный композитор должен написать свое бессмертное произведение, затем талантливый дирижер согласиться его исполнить, а все участники оркестра должны под его чутким руководством выучить и отработать необходимый материал. Итог работы будет зависеть от каждого участника (естественно в разной степени, никого не хочу обидеть, но вклад первой скрипки и парня с тарелками в заднем ряду сильно отличается).

Если мы посмотрим на разработку программных продуктов по классической водопадной схеме, то состав участников также будет довольно обширным: архитектор, тим лид, ведущие программисты, несколько программистов разной специализации (java, c/с++, javascript и тд) и группа дизайнеров с верстальщиками. Естественно далеко не все компании могут себе позволить идеально укомплектованный состав. Наиболее успешные организации могут заинтересовать в профессиональном и материальном плане более сильных специалистов, остальные конторы довольствуются тем, кто соответствует их уровню.

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

Под новым форматом я имею в виду небольшой творческий коллективов состоящий из 3-5 человек. Это еще не “оркестр”, но уже и не соло-программист. Естественно масштаб создаваемых произведений не сопоставим с творением Классики. Другими словами, если проводить аналогии, речь идет о коллективах создающие программы “по духу” более близкие к Yesterday Битлз, чем к Хорошо темперированному клавиру И.С. Баха.
Все идет к тому, что в программировании наступит время аналогичное музыкальной эпохи 60-70гг прошлого века.

У кого-то может возникнуть такая ассоциация:

у других такая: (далее…)