iBird Rose, насчёт посредника это понятно, я даже готов платить комиссию, задача в том, чтобы сервис был максимально простой. Binance достаточно замудрёный для клиентов, нужно что-то гораздо проще
Пума Тайланд, хаха, ну мне почему-то это кажется очевидным, люди хотят жить в безопасности или в шалаше, где им будут падать кирпичи на голову? для этого и нужна смета, думал все это понимают, поэтому использовал этот пример.
Владимир Куц, я вот что думаю, возможно наша проблема в том, что мы пытаемся совместить 3 должности: бизнес-аналитик, разработчик и продажник. И даже у этих троих, когда они работают каждый на своём месте, не всегда всё гладко выходит. Скорей всего надо специализироваться на какой-то одной бизнес-нише или нескольких, а остальные отметать. И тогда проще называть сроки и стоимость, но даже тут возможны киллер-фичи, конечно же, но всё равно проще работать, зная специфику сферы клиента.
Не каждый заказчик готов оплачивать проектно-изыскательские мероприятия.
Вот это больше всего и удивляет, ведь деньги на разработку проекта есть у всех и переплачивать 2-3 цены готовы большинство, а нормально заказать ТЗ что мешает? Явно не деньги, как правило, а что-то иное.
Да я пробовал уже много раз и доходчиво объяснять людям: вы же когда строите дом - заказываете проект, смету, которая учитывает почву и рельеф местности, положение коммуникаций, водозабора и тд, в которой посчитаны все материалы и виды работ, так почему вы не хотите заказать смету на создание вашего онлайн-проекта, чтобы также грамотно всё спроектировать и учесть риски? Воспринимают в штыки.
Василий Банников, как правило клиенты озвучивают то, что им надо, но не в полной мере, т.к.:
1. Они не всегда знают чего хотят и бизнес-требования меняются. Если бы было изначально составлено ТЗ куда можно их тыкать носом, когда они там у себя в голове всё перекручивают - работать было бы проще. Но, наверное, бизнесмены настолько творческие люди, что такое понятие как ТЗ и прочие рамки их отпугивают.
2. Они не всегда понимают технических деталей. И даже опытному разработчику потребуется время на ресёрч, чтобы их понять (изучить API вендора, например). И это время должно быть как-то оплачено, ведь это делается до написания даже единой строки кода, до старта проекта.
Я в посте указал про злосчастную фича_нейм, которая может просто убить проект либо затянуть по срокам. Яркий пример такой фичи - клиенту нужен магазин, но выгружать товары в него нужно с сайта поставщика. Делается магазин любым стандартным автоматизиованным способом не_с_нуля и делается коннектор к поставщику. А потом бац - выясняется, что много чего с сайта поставщика выгрузить либо нельзя, либо структура данных настолько отличается от того, что нужно для конкретного магазина, что приходится к коннектору писать ещё и свою базу, в которой хранить нормализованные данные для запросов с клиента (чтобы проект не тормозил, не генерил каждый раз данные на бэкенде, и клиент быстро получал правильные, обработанные данные сразу с базы). Это конечно не rocket science, но уникальность разных API и структур данных заставляет каждый раз наступать на одни и те же грабли - обещаешь клиенту, что будет готово в час х, а потом изучаешь API вендора и понимаешь, что придётся к магазину дополнительно насоздавать всяких костылей и всё затягивается. Если бы экспертиза такого рода оплачивалась изначально, то было бы проще называть конечный срок и стоимость, а также же будут названы все риски, в стиле "какие-то поля будут отсутствовать у некоторых продуктов, вы уж поймите" (реальный случай: у поставщика в 90 из 100 продуктов есть определённые поля, а у 10 из 100 - нет, но этого никто не заметил, а потом клиент фыркает, мол, плохо сделали, ничего не работает)
Василий Банников, а главная проблема это то, что есть риск наткнуться на функционал, который клиент забыл озвучить вначале или неправильно его огласил при первом знакомстве и потом этот функционал всплывает в виде затянутых сроков (когда нет готовой либы и всё пишется с нуля) либо вообще фейлом всего проекта (когда ожидаемый функционал клиента/проекта завязан на вендора к которому нет API)
Василий Банников, пробовал, в итоге всё заканчивается кратным увеличением сроков и стоимости. Т.к. все хотят быть уникальными и у всех какие-то уникальности всплывают рано или поздно, которые нужно делать и на которые не было запланировано время.
Вот с этим согласен. Голосовые вызовы пустая трата времени и невозможно понять, чего хочет заказчик, как правило. И, к сожалению, таких становится всё больше и больше.
NewDevLab, странно, мне в банке сказали считать по поступлениям в банк (их бухгалтерия именно так считает). Кроме того, как налоговая узнает сумму сделок на апворке, интересно?
Виталий, есть только некое противоречие между мной и компанией, на данном этапе компания вынуждена работать без лимитов, но лично я готов сбавить темп в любой момент, то есть ограничить разработчиков в часах работы, чтобы избежать переработок и иметь запас прочности
Vitsliputsli,
>Поэтому чтобы такого не было, обычно запрещен force push в master или вообще все только через pull request.
так ничто не мешает им в девелоперской ветке творить чудеса. или инструментов для слежения появляется больше?
>смотрите git log там будут все коммиты, в том числе перезаписанные.
там тоже самое, что в gitlab commits. вообще, если бы не gitlab activity, то я бы не узнал об этих чудесах
Думаю, что розовый разраб просто сделал amend всем комитам жёлтого и поэтому там в логах нет нигде жёлтого