Комментарии 104
Но вообще есть смысл смотреть, что именно просят чинить. Одно дело — допущенные программистом ошибки. Совсем другое — неоговоренные функции дописать, или учесть условия работы, о которых не договаривались.
Иначе будет — «нагрузка 10 RPS в ТЗ»… прошло 3 года… «парни, у нас 20k RPS, сервер не справляется, чините, это ваша ошибка».
И тот факт, что в проект заложены были JOIN между таблицами
Я давно не серверщик. Можете дать авторитетную ссылку, пожалуйста, которая говорит, что джоины и кластеризация — несовместимы и приводятся альтернативные рекомендации?
Тут, скорее всего, вольно употребление слова кластер. Читать следует "три отдельных базы данных"
а кластер из трех экземпляров Oracle
Под кластером серверов/БД/… в ИТ обычно имеют введу несколько экземпляров, объединённых так, что для клиентов они выступают как один сервер. Не знаю как в Oracle, но в PostgreSQL нельзя выполнить джойн между разными базами данных, независимо от того на одном экземпляре СУБД они крутятся или нет (вернее можно подключить внешний источник данных, прежде всего другую базу, но не тот кейс, кажется). С другой стороны, если несколько экземпляров СУБД объединены в кластер, то запросы в пределах одной базы данных можно выполнить на любом из экземпляров.
Судя по тому, что вы описываете, у вас не кластер, а просто три разных базы данных, а вы рассчитывали на три схемы в пределе одной базы данных. И практически не важно, один это экземпляр СУБД, на котором эти три базы крутится, три независимых экземпляра каждый со своей базой или кластер из трёх экземпляров, по которому "размазаны" эти три базы.
Ну, если бы мне что-то подобное рассказывали на старте, я бы спросил "у нас база одна будет или как?", мне бы сказали "кластер из трех экземпляров" и я бы успокоился — без разницы практически кластер или один сервер БД. Можете исключить, что что-то подобное и было на самом деле, просто терминология неточная?
Ну то есть — это не техническая проблема. Если бы всего один болван заранее спросил бы, куда мы будем развертывать все добро, и попросил бы схему, где нарисовано, что и куда — там бы уже было бы видно все. И вопросы были бы заданы.
почему это нельзя? можно, конечно, производительность только немного пострадает...
Можно установить связь foreign table :)
P.S. Заметьте, что дело происходит у заказчика. Вы приходите к DBA заказчика (это другая компания, и вы ему никто), и говорите ему — чувак, нам нужно сделать вот тут link на вон ту базу (потому что это — функция админа). Зачастую он вас посылает достаточно далеко — потому что об этом нужно было думать чуть раньше, чем за неделю до прома. И думать должен не разработчик, и к DBA ходить тоже не разработчик. Вот об этом и была история.
РП ставил задачу и налажал с запретом JOIN? — Так РП в отличии от программиста систему заказчика видит опосредованно, через призму документации, которая всегда отстает от реальности. Документацию готовят аналитики. Решение строят архитекторы. Но у разработчика есть прямой доступ к системе и среда тестирования. Сколько копий было сломано, что кластеризация и отказоустойчивость в тестах должны быть аналогичны продуктиву, иначе вот такие сюрпризы с JOIN. И что тогда мешало программисту или тестировщику заблаговременно заметить предстоящую сложность? Ах тестов производительности нет? Вообще не тестировали? На архитектора денег не хватило? Тесты на простой БД, а в проде кластер 3node active? Документация не просто отстает, а отсутствует? Аналитиком назначили штатного помощника менеджера? Вчера на проект наняли? И техническое задание и требования делали без консультантов? Так РП вот каждый этот вопрос записывает в журнал рисков. По каждому риску уже команда оценивает варианты реализации, вероятность и влияние каждого. А заказчик принимает. И вариантов не так много, ибо в большинстве случаев, минимизация рисков ведет к увеличению бюджета, а привлечение дополнительных спецов в проект вовсе нелинейно влияет на его качество и сроки. Так что чаще рискуем. Хочется верить осознано. А стоимость риска либо изначально в стоимости часа заложена и сроки жестко ограничены, что стимулирует бизнес консалтера/интегратора к найму лучших и предоставлению качества. Либо стоимость часа по-меньше выбираем и сроки плавающие, тогда консалтеру/интегратору выгоднее прислать к вам джунов по цене сеньеров. Да, этотне исключает, чтоту джуна все получится или сеньер накосячит. И истина где то посередине. А управляющий комитет проекта и РП следят за балансом и расставляют приоритеты.
На самом деле — все еще хуже. РП вообще не ставил задачу. Он не привлек для этого аналитиков. Он не обеспечил сред тестирования (тем более — идентичных планируемому прому). Он вообще не сделал ничего. А факап пытался списать на программистов.
>На архитектора денег не хватило?
Это тоже должны были сделать программисты? Да неужели?
должны быть аналогичны продуктиву, иначе вот такие сюрпризы с JOIN. И что тогда мешало программисту или тестировщику заблаговременно заметить предстоящую сложность
Он когда заметил и говорил, и писал об этом. Только кто его будет слушать?
Да выслушать может и выслушают, то скажут "Я тебя услышал, но пока это не актуально, вернёмся к вопросу позже". И даже возвращаются, когда прод или деплой на него падает, а при анализе инцидента выясняется что на имеющихся тестовых средах проблему воспроизвести нельзя было в принципе. Ещё и упрекают "почему ты недостаточно настойчиво продвигал новую тестовую среду?"
Все проще.
Тот, кто ставит какие-то дополнительные вопросы в начале проекта, просто не доживет до его конца.
Да и до середины не доживет… За забором множество послушных молчаливых джунов.
Это наверное в гугле так работают...
У меня на одной работе у РП было три аргумента, перекрывающие все другие аргументы ото всех других членов команды:
- ну и что
- все равно
- я же сказала
Задача у нее была не обозначить какие-то там риски, а максимально сгладить всё-всё-всё перед клиентом. То есть любое обсуждение любой задачи с клиентом должно было сводиться к "проблем нет и не будет, сделаем завтра".
Нанимал ее генеральный, она его устраивала полностью.
На нынешней работе РП — сам генеральный. На компьютере он конечно как-то работает, но например про Ctrl+F в браузере впервые в жизни услышал в прошлом году...
Таковы сегодняшние реалии.
Можно я уточню, баги в коде влияют на репутацию?
Упс… У кого код без багов, поднимите руку.
Не сам факт их наличия, но их частота, условия возникновения, условия, в которых код написан.
Если баги лезут из экспериментального кода, который никто не тестировал — это одно дело. Если баг лезет под высокой нагрузкой, да ещё и в специфичных условиях — тоже понятная история. А если баг возникает в очевидных условиях, а особенно, если баг был в трекере и закрыт (или был такой же баг в соседней ручке) — то вот такое на репутацию уже точно влияет, если постоянно случается.
Поскольку баги у всех и у всех от этого меняется репутация, то относительная репутация не меняется.
Либо кто-то пишет код без багов.
Кто-то пишет багов меньше этой планки — и получает прирост репутации. Кто-то пишет ниже планки — и получает минусы в репутацию, вплоть до увольнения. В другом месте планка будет другой.
А ещё есть аналогичный параметр репутации у компании в целом. Какую-то аутсорс контору будут считать багописателями (а оно по сарафанному радио быстро разлетается между потенциальными заказчиками) и ничего важного им никогда не доверят. Или вот игры от blizzard покупать теперь будут только после того, как поиграют в спираченные.
Вот, смотрите, у нас есть четыре софтописательные конторы:
- Майкрософт
- Гугль
- Эппл
- Амазон
У кого какая репутация? Какое ожидаемое число багов от этих компаний? Почему оно одинаковое/разное?
Есть репутация, есть. Просто она уже воспринимается как «это моё мнение, я так 5 лет считаю». Наверняка же вот считаете, что sennheiser делают хорошие наушники =) Или что blackberry — это какие-то инопланетные телефоны из прошлого века.
Вот sennheiser — выезжает на своей репутации. А blackberry из-за этой самой репутации лапки откинул. При том что sennheiser после ~2012 ничем не выделяется (у beyerdynamic всегда есть ответ получше), а blackberry на закате пилил телефоны на обычном андроиде, которыми никто не интересовался, потому что «ой, это blackberry? как ты с ним живёшь-то без приложений!».
Или, скажем «40 минут. Читал сегодняшний хабр со всеми комментариями в надежде найти что-то, что позволит поднять эффективность работы. Не нашёл». И не понятно, как трекать ситуацию, когда от усталости или недосыпа мозг переходит в неадекватный режим работы и генерирует сюр, а оплата почасовая, поэтому заканчивать никак нельзя, если хочется зарплату.
Скажите, а сколько часов по-вашему работает в день программист?
А почему столько?
Хотелось бы услышать аргументацию про медлительных и быстрых и увидеть критерии оценки скорости.
Спасибо.
Вы без воды можете цифру озвучить?
И критерий определения эффективности работы «быстрого»/«нормального»/«медленного» разработчика.
Ну, чтобы стало понятно за что кому и сколько платить.
Без вот этих «чувств» и «желаний».
Если найдете того, кто сможет — позовите пожалуйста.
В конце концов заказчик будет оценивать общий объём и скорость работ и выставленную оплату.
Вот именно! По этому сразу лучше считать этот объем работ и скорость. Но! Ведь хотят сэкономить используя психологические приемы — рассчитывают, что если платить абонплату и как-то мотивировать словами (молодец, супер, ты умница и т.д. — список слов можно получить на разных тренингах) от начальства — то смогут за меньшую стоимость получить большую отдачу.
Собственно — по Марксу способность выжать из работника результат заплатив чем меньше (т.н. прибавочная стоимость) — это и есть главный секрет обогащения. Человек же существо социальное — всякие корпоративы, культура, должности и т.д. — все это позволяет увеличивать прибавочную стоимость.
Очень мудрые слова, это высокие ценности, но работа по часам — это принципиально более высокий уровень стресса, что не полезно для хороших программистов.
А не будет ли программист затягивать работу при оплате по часам?
1. Сказать что работа, которую ты делал 5 часов — должна была занять 1 час, по этому получишь денег как за 1 час. В этом случае тогда нафиг не нужны были часы — сразу сказать что за эту работу столько то денег.
2. Терпеть и платить за часы, но по итогам месяца сказать, что ты слишком медленно работаешь, по этому понижаем ставку в 2 раза.
Как так может быть правильней, если речь о реальных сроках, а не абстрактных сторипоинтах? Один хорошо знает систему в целом, другой ещё лучше, но только конкретную её часть, третий в целом программист лучше чем эти два вместе взятые, но ещё даже формальный онбординг на проекте не прошёл. Очень легко получить ситуацию, когда сроки реальные для одного абсолютно не реальны для другого.
В этом случае тогда нафиг не нужны были часы — сразу сказать что за эту работу столько то денег
Скажите, как часто в вашей практике профи может точно оценивать объём работ?
На чужом несчастье своего счастья не построишь
Почему несчастья? Чел. может выдавать результат и радоваться что его ценят — деньги могут быть не на первом месте.
почасовка как раз более справедлива
Почасовка — такая же фикция. Нужны то не жопочасы а результат. Можно работать быстро, можно медленно — зависит от множества факторов — не обязательно специально тормозить. Депрессия, выгорание, сложные обстоятельства — вот уже за час чел. делает в 3 раза меньше работы, чем раньше. Начинаешь ругать и тыкать носом — становится хуже.
Ну или еще вариант — проведение ревью кода, после чего оценка объема кода (без ревью — получите раздувание кода). Но тут тоже нужно быть специалистом.
В общем — как ни крути — а оценка труда требует затрат. И часы ничем не помогут.
По моему опыту, привлекают на часовую оплату из желания сэкономить, типа мы не сможем загрузить человека на 168 часов в месяц, поэтому давайте по часам ему платить — дешевле выйдет. Хотя при загрузке часов на 80 уже дороже выходит навскидку.
Конечно, тут последует стандартный совет сменить работодателя, но ещё и не всем это легко даётся.
А менять работодателей — конечно, тяжело всем и всегда. Но почасовка и это позволяет делать более мягко и постепенно, не выпуская синицу из рук, пока тянешься за журавлём в небе.
Грязное проще посчитать.
Предположим у вас три новых магазина и решено поставить эксперимент. Первый делает штатная команда, на штатном решении. Второй отдаем самому лучшему интегратору/консалтеру. Третий — самому дешевлму с часовой ставкой.
Прошло три месяца, первый магазин уже работает. Второй сияет современными решениями. Третий работоспособен, но постоянно какие то проблемы.
Израсходованный бюджет на открытие первого, 10 млн, второго 20млн, третьего 5млн. С кем продолжим работать, когда понадобится еще 10 магазинов?
С кем
Очевидно же — будем искать на услоыном апворке еще дешевле.
Когда специалист вырабатывает 40 часов в неделю / 20 дней в месяц и больше, работает на нас более 3х месяцев, показывает результат => платим оклад. Иначе, платим по часам. Премии до 20% годового оклада по интегральному критерию на основе финансового результата работы всей компании (объективная оценка) и личного вклада (субъективная оценка) для тех кто достиг определенного грейда и работает с нами больше года
В качестве кого вы защищаете почасовую оплату? Программистов самих спрашиваете? И о каких продуктах или проектах идёт речь?
Можете кратко рассказать какие такие отношения вы считаете правильным. Вот я программист, допустим, работаю в компании на проекте одного заказчика. Компания с заказчиком договорилась об объёме работ, сроках (привлекая меня для оценки) и стоимости (все понимают, что её основа — сроки * рейт). Я работаю на окладе, если сделаю в оговоренные сроки, то всем нормально, ожидаемый результат. Сделаю медленнее — все будут не рады. Сделаю чуть быстрее, все, наверное будут рады и, может быть мне премию дадут. Сделаю заметно быстрее — моя компания будет рада, наверное, и даже премию дадут, но, вероятно это по факту будет выходным пособием. У заказчика же, вполне может быть, останется мнение, что его обманули — рассказывали, что работы на полгода, оплату соответственно взяли, а сделали за месяц. Кому тут поможет, если у меня будет почасовая оплата?
Ок, допустим что-то вроде скрама с оплатой заказчиком по каждому недельному спринту. Допустим планируем на программиста по 30 часов чистого программирования и 10 часов сопутствующей деятельности (общение с заказчиком, своими менеджерами, с коллегами-программистами, с тестировщиками, с админами-девопсами и т. п. — это же время так же оплачивается как и программироание, да?). И в целом в оценки попадаем, где-то переоценили, где-то недоценили — то на то и выходит. В результате каждый отрабатывает по 40 часов, заказчик оплачивает одну и ту же сумму до копейки раз в неделю. Кому тут выгода?
А если я задачу недооценил, то что? Заказчик оплачивает недоделанную задачу? Или я овертаймлю, задачу таки доделываю, но заказчик платит больше за неделю чем рассчитывал. А если переоценил, то сижу бездельничаю и получаю меньше за эту неделю? или с заказчика берут по полной, а только мне платят больше?
Вот в чём мне, программисту, смысл переходить на почасовую оплату в отношениях с моей компанией (подрядчиком заказчика по сути), если отрабатываю я по 40 часов в неделю, овертаймить возможности нет (worl/life баланс и всё такое), но есть всякие праздники и их переносы, уменьшающие количество рабочих часов в неделю, есть всякие феврали, уменьшающие количество рабочих часов в месяц, что делает при постоянной работе по 8 часов в день неравномерным месячный доход. в чём мне выгода, в чём мои, как программиста, плюсы?
То есть это не почасовая оплата программисту, с которой всё начиналось:
Мне регулярно приходится защищать почасовую оплату труда программистам.
а простое осмечивание. Оценили фронт работа в часах программистов (конкретных или средних джун/миддл/сеньор), посчитали в деньгах, добавили накрутку на орграсходы и прибыль и выставили заказчику счёт. Программист же получает по сути фикседпрайс за задачу, становится не работником, а субподрядчиком, пускай и с элементами трудовых отношений (отпуска, больничные и т. п.). Сделал быстрее чем по смете — получает те же деньги за большее время, задержал (по своей вине) — работает больше за те же деньги. Так?
Но некоторое совмещение в виде «постоянной» и «переменной» частей команды было бы интересно, в том числе разработчикам, которые хотели бы иногда снизить нагрузку с 40ч. в неделю до произвольного меньшего значения. В идеале мог бы сформироваться качественный рынок предложения услуг по разработке, в том числе от индивидуалов. Сейчас же ситуация для индивидуалов, по сути, неконкурентоспособна по доходу в сравнении с постоянным наймом.
В общем — пусть Вкусвиль экспериментирует. У них задачи пока мелкие, поэтому обычный фриланс их тянет. Но вот подрастут (если сумеют, конечно), тогда объективно встанет задача координации усилий по разработке. Хотя может и не дорастут до такого размера, а потому ни на что на рынке не повлияют.
Хотя автор, похоже, по сути пиарит свою книжку про бирюзовое управление. Тогда вообще конструктивного диалога не выйдет — цели у него не соответствуют диалогу.
То, что все компании по-разному оплачивают работу программистов, и не только мы платим за часы, видно из результатов опроса выше. Крестить мы никого не крестим. Чистая почасовка. Объяснял это в других сообщениях «рекламирующих» данных способ работы выше. То, что он имеет свои минусы — согласен и разбирали там же, в том числе и с моим участием. Плюсы тоже привёл.
По тому, что задачи у нас не «Гугла» — тоже полностью согласен, поэтому и хотелось бы сравниться именно с ситуацией в других розничных компаниях сопоставимых по размеру или даже больше, с кем советуют сравниваться старшие товарищи. Если кто-то знает, то напишите, пожалуйста: лучше там реализовано взаимодействие с программистами, чем у нас или хуже? И на каких принципах всё это оплачивается?
Теоретически им вряд ли было бы выгоднее нанимать админа и отдельно почасового разработчика. Админ бы не сильно меньше получал, но зато никаких гарантий от чужого разраба. А свой всё же был всегда под рукой, пока простаивал — з/п за админство начислялась (ну или оправдывалась в глазах директора).
Вообще если контора не очень большая (сотня-две человек), то тесные отношения с разработчиком полезны. Хотя разумеется, сначала нужно найти подходящего.
Ну а в больших конторах, или даже в средних, но которым нужно что-то приличное по размеру разрабатывать, стоимость потерь из-за отсутствия координации резко нарастает. Даже в сетях ERP на всю контору с учётом массы деталей очень даже требует координации. Если это покупной продукт, то координация по внедрению и настройке. Если кастом — тут вообще много задач, которые можно было бы сделать один раз, вместо десятков для каждого фрилансера.
В общем я за координацию. Может даже её можно вынести на почасовую оплату, типа один архитектор мониторит несколько заказчиков. Но всё равно без неё потери будут значительные.
Но с другой стороны — есть в бюджете строчка «расходы на ИТ» и ею начальство довольно — вот и нет нужды что-то координировать. Если у вас так, то это ни чем не обоснованный подход, кроме как экономией времени и нервов того, кто строчки в бюджете оценивает.
У методологии потенциально есть место под солнцем. Но широкое её распространение, как и существенный рост для любого стартапа, совершенно не гарантировано. Скорее очень вероятно, что всё так и останется в рамках одной компании и вы лишь получите интересный опыт, но не более.
Но может и удастся упаковать и продать методологию другим средним предприятиям. Тогда бы возможно стал возможен вариант «неполной ставки» для тех, кому время важнее денег. Этим подход интересен. Но дьявол, как известно, в деталях. Поэтому может получиться плохо. А может и хорошо. Я со стороны разработчиков голосую за «хорошо», но понимаю, что всё это лишь очередной стартап с непонятными перспективами.
Оплата почасовая, за результат или оклад?