У второй схемы есть ещё одна проблема. Заказчик и исполнитель попадают в режим споров друг с другом о необходимости включения или исключения каких-либо работ из предоплаченного пула. Начинается юридическая волокита, которая должна защитить интересы каждой из сторон, но они обе теряют от такого положения дел: и силы, и время, а значит и деньги. А если сесть и честно посчитать эти пустые затраты, то они могут составить до 40% от стоимости и до 60% от времени проекта. Данные получены мной лично эмпирически из сравнения стоимости и сроков реализации аналогичных проектов в сопоставимых компаниях. Удивительно, но уже сильно позже, читая книгу Стивена Кови «Скорость доверия» я прочитал про аналогичные данные, полученные им уже для американских компаний.
Есть ещё окладная или абонентская система оплаты, которая, может показаться ещё лучше, чем почасовая оплата, так как не надо тратить силы и время на подсчёт и выставление часов, а также защиту их от возможного завышения. Но мне она не нравится тем, что тогда программист не всегда радуется работе, как в случае с почасовкой, а заказчик не всегда осознаёт, сколько он тратит денег компании, так как пользуется как бы бесплатным для него ресурсом.
Да, если что, сам я заказчик и работаю на стороне заказчика всегда, поэтому писал всё это из данной позиции.
Dimond17
Что с таким подходом мешает программистам специально наделать багов в программе, чтобы им заплатили ещё раз за их «исправление»? Лучше уж поднять цену часа и гарантировать качество продукта, так заказчику будет понятнее за что он платит
tema_sun
Если код будет регулярно работать плохо, то с таким программистом расстанутся очень быстро.
inkvizitor68sl
Репутация.
Но вообще есть смысл смотреть, что именно просят чинить. Одно дело — допущенные программистом ошибки. Совсем другое — неоговоренные функции дописать, или учесть условия работы, о которых не договаривались.
Иначе будет — «нагрузка 10 RPS в ТЗ»… прошло 3 года… «парни, у нас 20k RPS, сервер не справляется, чините, это ваша ошибка».
sshikov
Бывает и еще проще. За две недели до внедрения: «Ой, а мы вам забыли сказать, у нас тут будет не одна база данных и три схемы в ней, а кластер из трех экземпляров Oracle». И тот факт, что в проект заложены были JOIN между таблицами, рассматривается как ошибка программистов. В то время как на самом деле налажал тот, кто ставил задачу, а именно РП скорее всего.
inkvizitor68sl
Да, такой пример намного лучше подходит =)
TheShock
Я давно не серверщик. Можете дать авторитетную ссылку, пожалуйста, которая говорит, что джоины и кластеризация — несовместимы и приводятся альтернативные рекомендации?
VolCh
Тут, скорее всего, вольно употребление слова кластер. Читать следует "три отдельных базы данных"
sshikov
Так я еще и пояснил, что это «три отдельных экземпляра». Вот казалось бы, что тут непонятного? Нельзя выполнить JOIN между тремя отдельными базами.
VolCh
Под кластером серверов/БД/… в ИТ обычно имеют введу несколько экземпляров, объединённых так, что для клиентов они выступают как один сервер. Не знаю как в Oracle, но в PostgreSQL нельзя выполнить джойн между разными базами данных, независимо от того на одном экземпляре СУБД они крутятся или нет (вернее можно подключить внешний источник данных, прежде всего другую базу, но не тот кейс, кажется). С другой стороны, если несколько экземпляров СУБД объединены в кластер, то запросы в пределах одной базы данных можно выполнить на любом из экземпляров.
Судя по тому, что вы описываете, у вас не кластер, а просто три разных базы данных, а вы рассчитывали на три схемы в пределе одной базы данных. И практически не важно, один это экземпляр СУБД, на котором эти три базы крутится, три независимых экземпляра каждый со своей базой или кластер из трёх экземпляров, по которому "размазаны" эти три базы.
sshikov
Возможно вы не поняли, но я говорил вообще о другом — о том что тот долбодятел, который обязан был об этом подумать, в этом случае вообще не подумал, и никому ничего не рассказал (ну и сам не узнал, соответственно) о том, какова будет структура прома. А все остальные детали меня вообще не волнуют, потому что к делу в этом случае не относятся.
VolCh
Ну, если бы мне что-то подобное рассказывали на старте, я бы спросил "у нас база одна будет или как?", мне бы сказали "кластер из трех экземпляров" и я бы успокоился — без разницы практически кластер или один сервер БД. Можете исключить, что что-то подобное и было на самом деле, просто терминология неточная?
sshikov
А представьте что это у вас десятый похожий проект. Или пятидесятый. И никогда не было такого, чтобы было «или как» — потому что это нафиг не нужно никому (включая этого заказчика тоже). И при этом все остальное в проекте вполне себе горит синим пламенем, потому что _тот же самый долбодятел_ пообещал заказчику нереальные сроки, помимо всего прочего. И вас посылают делать одну работу, а в итоге выясняется, что работы этой намного больше, и другой.
Ну то есть — это не техническая проблема. Если бы всего один болван заранее спросил бы, куда мы будем развертывать все добро, и попросил бы схему, где нарисовано, что и куда — там бы уже было бы видно все. И вопросы были бы заданы.
RazVal Автор
Отличный пример! В нашем случае ответственность ляжет именно на эту птицу, так как программист делает и получает за часы. Не устраивает программист? — Бери другого! — Опять такая же ситуация? — Бери третьего. — Все 10 программистов плохие, хотя других заказчиков они полностью устраивают? — Сам всё понимаешь.
zxweed
почему это нельзя? можно, конечно, производительность только немного пострадает...
sshikov
Если это реально независимые экземпляры — то один из них вообще ничего не знает про другие. Кто с чем будет делать JOIN?
VolCh
Можно установить связь foreign table :)
sshikov
Гы. Ну вот мы это в конечном счете и сделали. И при чем тут это?
P.S. Заметьте, что дело происходит у заказчика. Вы приходите к DBA заказчика (это другая компания, и вы ему никто), и говорите ему — чувак, нам нужно сделать вот тут link на вон ту базу (потому что это — функция админа). Зачастую он вас посылает достаточно далеко — потому что об этом нужно было думать чуть раньше, чем за неделю до прома. И думать должен не разработчик, и к DBA ходить тоже не разработчик. Вот об этом и была история.
VolCh
Что можно сделать джойн :)
sshikov
А теперь представьте, что нельзя сделать линк. DBA отказал, потому что безопасность. И все.
wmgeek
РП ставил задачу и налажал с запретом JOIN? — Так РП в отличии от программиста систему заказчика видит опосредованно, через призму документации, которая всегда отстает от реальности. Документацию готовят аналитики. Решение строят архитекторы. Но у разработчика есть прямой доступ к системе и среда тестирования. Сколько копий было сломано, что кластеризация и отказоустойчивость в тестах должны быть аналогичны продуктиву, иначе вот такие сюрпризы с JOIN. И что тогда мешало программисту или тестировщику заблаговременно заметить предстоящую сложность? Ах тестов производительности нет? Вообще не тестировали? На архитектора денег не хватило? Тесты на простой БД, а в проде кластер 3node active? Документация не просто отстает, а отсутствует? Аналитиком назначили штатного помощника менеджера? Вчера на проект наняли? И техническое задание и требования делали без консультантов? Так РП вот каждый этот вопрос записывает в журнал рисков. По каждому риску уже команда оценивает варианты реализации, вероятность и влияние каждого. А заказчик принимает. И вариантов не так много, ибо в большинстве случаев, минимизация рисков ведет к увеличению бюджета, а привлечение дополнительных спецов в проект вовсе нелинейно влияет на его качество и сроки. Так что чаще рискуем. Хочется верить осознано. А стоимость риска либо изначально в стоимости часа заложена и сроки жестко ограничены, что стимулирует бизнес консалтера/интегратора к найму лучших и предоставлению качества. Либо стоимость часа по-меньше выбираем и сроки плавающие, тогда консалтеру/интегратору выгоднее прислать к вам джунов по цене сеньеров. Да, этотне исключает, чтоту джуна все получится или сеньер накосячит. И истина где то посередине. А управляющий комитет проекта и РП следят за балансом и расставляют приоритеты.
sshikov
>РП ставил задачу и налажал с запретом JOIN?
На самом деле — все еще хуже. РП вообще не ставил задачу. Он не привлек для этого аналитиков. Он не обеспечил сред тестирования (тем более — идентичных планируемому прому). Он вообще не сделал ничего. А факап пытался списать на программистов.
>На архитектора денег не хватило?
Это тоже должны были сделать программисты? Да неужели?
gluck59
Он когда заметил и говорил, и писал об этом. Только кто его будет слушать?
VolCh
Да выслушать может и выслушают, то скажут "Я тебя услышал, но пока это не актуально, вернёмся к вопросу позже". И даже возвращаются, когда прод или деплой на него падает, а при анализе инцидента выясняется что на имеющихся тестовых средах проблему воспроизвести нельзя было в принципе. Ещё и упрекают "почему ты недостаточно настойчиво продвигал новую тестовую среду?"
gluck59
Все проще.
Тот, кто ставит какие-то дополнительные вопросы в начале проекта, просто не доживет до его конца.
Да и до середины не доживет… За забором множество послушных молчаливых джунов.
VolCh
Это преувеличение, имхо. Можно жить годами на проекте, ставя дополнительные вопросы, поднимая проблемы. Просто без особого результата.
wmgeek
В обязанности программиста не входит — продвижение риска. Есть обязанность — участвовать в правильной формулировке и оценке. Но владелец риска — это другое лицо — главный инженер, архитектор, тимлид, руководитель программиста, РП, спонсор проекта и т.п. Попытка сделать владельцем риска исполнителя работ приведет лишь молчанию. Реестр рисков решает эту проблему. Риск без владельца или где владелец = исполнителю (инициатору) без его прямого согласия — косяк РП. И на то есть руководитель проектного офиса, аудитор, спонсор проекта и управляющий комитет в целом. Они могут плохо реагировать на сложные вопросы, но такие простые вещи как: «Я сформулировал риск, а РП не занес его в реестр» — решают легко и быстро.
VolCh
Вы вот сейчас перечислили людей больше, чем у нас в компании всего, если не считать операционистов. :)
wmgeek
Одна из обязанностей РП — занести в реестр рисков любое сформулированное в виде риска замечание любого участника проекта. Даже если в замечании бред сивой кобылы — запись остается в реестре, ей присваивается вероятность, влияние и выбирается стратегия — принять риск, смягчить, исключить или передать. Под риском в реестре так или иначе подпишется заказчик. И если он реализуется, претензии могут быть только к формулировке. А кто формулировкой занимался? — И тот кто говорил, и тот кто оценивал, и РП. Но у каждого риска свой владелец. И задача РП вовсе не столько в том, чтобы устранить все риски или абсолютно правильно их сформулировать, а прежде всего в том, чтобы риски были учтены, обсуждены, оценены и не остались без внимания заинтересованных сторон.
gluck59
Это наверное в гугле так работают...
У меня на одной работе у РП было три аргумента, перекрывающие все другие аргументы ото всех других членов команды:
Задача у нее была не обозначить какие-то там риски, а максимально сгладить всё-всё-всё перед клиентом. То есть любое обсуждение любой задачи с клиентом должно было сводиться к "проблем нет и не будет, сделаем завтра".
Нанимал ее генеральный, она его устраивала полностью.
На нынешней работе РП — сам генеральный. На компьютере он конечно как-то работает, но например про Ctrl+F в браузере впервые в жизни услышал в прошлом году...
Таковы сегодняшние реалии.
amarao
Можно я уточню, баги в коде влияют на репутацию?
Упс… У кого код без багов, поднимите руку.
inkvizitor68sl
Баги в коде влияют на репутацию, да.
Не сам факт их наличия, но их частота, условия возникновения, условия, в которых код написан.
Если баги лезут из экспериментального кода, который никто не тестировал — это одно дело. Если баг лезет под высокой нагрузкой, да ещё и в специфичных условиях — тоже понятная история. А если баг возникает в очевидных условиях, а особенно, если баг был в трекере и закрыт (или был такой же баг в соседней ручке) — то вот такое на репутацию уже точно влияет, если постоянно случается.
amarao
Поскольку баги у всех и у всех от этого меняется репутация, то относительная репутация не меняется.
Либо кто-то пишет код без багов.
dikkini
вам говорят «частота багов, условия возникновения, работоспособность кода», вы заладили, никто не пишет код без багов.
amarao
Я первый раз в жизни слышу, чтобы частота багов была фактором оценки качества работы программиста. Архитектура — да. Кривизна в коде (когда никто не может разобрать что написано) — да. Срезание углов и халтура — да.
Про баги первый раз слышу.
VolCh
Есть такие KPI типа сколько раз разработчику задачу тестировщики возвращают на доработку. Конечно с привязкой к сложности и объёму задачи, но тем не менее встречается.
amarao
Я знаю, некоторые таким страдают. Ещё веселее, когда у QA обратная метрика — чем больше задач вернул назад, тем лучше.
inkvizitor68sl
Есть планка «нулевой репутации» с н-ным ожидаемым количеством багов. Планка везде своя.
Кто-то пишет багов меньше этой планки — и получает прирост репутации. Кто-то пишет ниже планки — и получает минусы в репутацию, вплоть до увольнения. В другом месте планка будет другой.
А ещё есть аналогичный параметр репутации у компании в целом. Какую-то аутсорс контору будут считать багописателями (а оно по сарафанному радио быстро разлетается между потенциальными заказчиками) и ничего важного им никогда не доверят. Или вот игры от blizzard покупать теперь будут только после того, как поиграют в спираченные.
amarao
Вот, смотрите, у нас есть четыре софтописательные конторы:
У кого какая репутация? Какое ожидаемое число багов от этих компаний? Почему оно одинаковое/разное?
inkvizitor68sl
Про МС ничего не скажу — 10 лет не слежу. У гугла репутация понятная — переделывают все свои сервисы и получается тормозное гомно (но багов ждёшь немного и чуть ли не каждую пятисотку на ютубчике скриншотишь, так уж они редки). От эппла ждёшь малое количество ошибок и проблем. А амазону нужно нанять специалистов по UX (впрочем, я и не помню, что они делают, кроме инопланетного AWS и самого магазина).
Есть репутация, есть. Просто она уже воспринимается как «это моё мнение, я так 5 лет считаю». Наверняка же вот считаете, что sennheiser делают хорошие наушники =) Или что blackberry — это какие-то инопланетные телефоны из прошлого века.
Вот sennheiser — выезжает на своей репутации. А blackberry из-за этой самой репутации лапки откинул. При том что sennheiser после ~2012 ничем не выделяется (у beyerdynamic всегда есть ответ получше), а blackberry на закате пилил телефоны на обычном андроиде, которыми никто не интересовался, потому что «ой, это blackberry? как ты с ним живёшь-то без приложений!».
RazVal Автор
Чем ещё хороша система независимых заказчиков и исполнителей, каждому исполнителю не обязательно обладать самой лучшей репутацией у всех заказчиков, а можно иметь достаточное количество заказчиков, которые удовлетворены твоей работой, чтобы они загружали тебя новой по полной.