Поймал негр золотую рыбку. - Отпусти меня, - говорит золотая рыбка, - Любое твое желание исполню. Подумал негр и говорит: - Сделай меня белым, и чтобы вокруг меня одни женщины были. Махнула рыбка хвостом… и превратила негра в унитаз в женском туалете. Будьте аккуратны с ТЗ
Аж фильм "войны Пентагона" вспомнился))) советую посмотреть всем чтобы темой проникнуться, особенно для работы с компаниями с большим административным ресурсом
В начале фриланс пути я сильно обжёгся на моменте с ТЗ. Пришла задача от хорошего знакомого, о чьих технических навыках я был хорошего мнения. ТЗ выглядело продуманным и подробным. Я проявил невнимательность, взял заказ и начал прорабатывать. По ходу дела оказалось, что в ТЗ много дыр, белых пятен и противоречащих друг другу пунктов. Разработка из-за этого усложнилась в геометрической прогрессии и необходимый бюджет сильно возрастал. В тот момент, попробовав объяснить специфику усложнения задачи, я слился с заказа. С тех пор если я вижу, что у заказа есть намёки на творческую сложность - я предлагаю проработку мной технического ТЗ как предварительную услугу. Если итоговое ТЗ для меня исполнимо - то делаем. Если нет - простите.
Ставлю лайк, за подачу и поднятие самой проблемы, но с автором во многом согласен и во многом не согласен одновременно. Занимаюсь разработками/доработками CRM систем уже более 5 лет, участвовал за это время в десятках проектов и поэтому считаю, что могу высказать и обосновать свое мнение. ТЗ это конечно хорошо в целом, тут полностью согласен, но бывает так, что разработать полностью детальное ТЗ, в котором бы были учтены все нюансы и детали, просто не возможно... У меня был негативные случай, когда разработкой ТЗ занималась целая проектная команда из PM, нескольких аналитиков и разработчиков (в качестве экспертов) на протяжении примерно полугода. Получился документ примерно в 1 тыс. страниц. Был потрачен почти месяц на детальную оценку, т.к. заказчик хотел знать заранее "сколько каждая кнопочка стоит в граммах". И в результате ничего! Заказчик остался недоволен потраченному времени и оценке (слишком дорого, они хотели все и за копейку), а я лично, как разработчик, полугодом потерянным на пустую писанину. Другой, тоже крупный проект, разработано и утверждено детальное ТЗ. Делаем первый этап четко по ТЗ, а заказчик говорит, что принимать и оплачивать работы не будет, т.к. он видел все по другому, а на ТЗ ему плевать и мы можем им подтереться... Еще пример, на этот раз позитивный, заказчик просит сделать доработки в CRM для внедрения собственной системы электронного документооборота и сбрасывает ТЗ (ну, почти ТЗ, скорее набор требований), которое очень похоже на документацию для Lotus Notes. В результате мастерски проведенных переговоров, договариваемся о разумном бюджете на квартал и работе в режиме T&M с еженедельными релизами. Через месяц заказчик полностью доволен доработкой документооборота, хотя мы сделали от силы 3% от изначальных требований. Оказывается именно это и в таком объеме ему и было нужно (сам он об этом в начале проекта даже на знал). Потом мы с этим заказчиком в таком же режиме работали несколько лет и все были довольны. А что было бы если бы мы на месяц другой ушли и стали разрабатывать полное ТЗ? В общем итог такой. ТЗ действительно нужно, но если не получается сделать его быстро и небольшого объема, то нужно договариваться на релизы, оговаривать объем работ (деньги) делать небольшое, но понятное ТЗ на один ближайший релиз и начинать делать и сразу показывать заказчику результаты, давая при этом вносить любые изменения, которые "влезают" в обговоренный скоуп работ. И тогда пример с велосипедом-ракетой не был бы такой страшный. Возможно еще при установке колес на велосипед выяснилось, что их должно быть 4ре, а не 2а. А когда дошли до автомобиля, то просто озвученная стоимость работ следующего этапа, заставила бы заказчика остановиться... Так у меня кстати было и не раз, когда "раздувающиеся" требования от бизнес-заказчика, жестко отвергались PM со стороны заказчика с формулировкой денег на такие "рюшки" нет.
В точку! Вспомнил про «прозрачную красную линию в форме котёнка». А по Agile, я думаю что для сложных проектов с хорошими требованиями к надежности нужен waterfall или подобные методологии, для быстрой разработки для создания MVP, нужны агилы. А вот ТЗ надо всем;)) ТЗ это как нарисовать мишень, есть понимание куда стрелять. Спасибо за видос!
Имхо какие-то вещи из agile разумны и работают, например, начинать проект с самого важного функционала системы, а затем по ходу проекта иметь возможность выкинуть что-то из менее важного, заменив его более важным, даже не входящим в изначальное ТЗ, но имеющим схожую трудоёмкость реализации. Система оценки задач внутри проекта по баллам интересна и вполне может использоваться. Но штука в том, что это всего лишь некоторые инструменты из большой agile методологии, то есть использование их это не есть использование agile в чистом виде:) Гибкости это добавляет, но не в том объёме, как заявляют приверженцы полностью гибких методологий
Согласен насчет необходимости ТЗ, но вот насчет сложности проектов разрешите вставить 5 копеек.) Agile как раз был придуман для мегасложного проекта, который несколько раз пытались сделать по ватерфоллу, но не получалось, потому что проект каждый раз делали так долго, что представления заказчиков или сама реальность банально успевали измениться (это была какая-то система для ФБР, которую делали в 1980-1990 гг. и наконец-то сделали в 1993 году, параллельно изобретя аджайл). Наличие изначальных требований к безопасности и надежности продукта никак аджайлу не противоречит. Идея аджайла скорее в том, чтобы заставить заказчика и исполнителя чаще друг с другом коммуницировать и в процессе этой коммуникации уточнить все требования, которые заказчик забыл указать в изначальном ТЗ и реализацию которых не заложили в вотерфоле (ну и новых требований, которые появились уже в процессе работы над проектом, после подписания ТЗ).
@@t0digital Просто истина, всегда где-то посередине: например в СССР проработка ТЗ занимала намного больше, времени и иногда доходила до абсурда. Та же лунная база, разработка тз которой заняла более 10 лет, а итогом встал вопрос о невозможности все профинансировать, или была шахта, которую построили вроде за год, а разработка тз длилась 20 лет. В то же время сейчас пошла мода на абстрактные проекты, которые невозможно сдать и невозможно принять.
Из моего личного опыта. Заказчик очень часто, особенно в небольших лавках, сам не представляет что и как. Фраза после которой я обычно посылаю заказчика - "Ну сделайте как-нибудь". Понял что ничего хорошего с такими заказчиками не получится.
Заказчик действительно часто многое не понимает в той сфере, в которой нанимает исполнителя - но это и нормально, для того спецы и нужны, которые рубят в своей теме и помогают тем, кто в этой теме не рубит. Адекватные заказчики прислушиваются к разумным доводам исполнителя о том, как всё стоит сделать. А с неадекватными работать не стоит:)
Лол, ты прав. Для этого и нужны, прости господи, маркетологи и сейлы, чтобы в такой ситуации убедить заказчика, что для него сделано не просто какое-то г. с синхронизацией на слипах, а революционный передовой продукт, красоте и совершенству которого нет предела.
@@Ronin34rus для этого нужен независимый технический консультант такой человек может объяснять сложные вещи понятным языком и по сути является интерфейсом между заказчиком и исполнителем например есть у меня клиентка и она говорит на русском, но у нее магазин на немецком и связан с немецким поставщиком по европам у поставщика дока на их формат данных на немецком и русскоговорящие дешевые фрилансеры не берутся за эту работу, потому что не знают немецкого и не знают, чего хочет тетка а я знаю чего она хочет, чего ей надо сделать, чего надо сделать исполнителю, как это надо сделать и могу перевести доку на русский и нарисовать интерфейс и объяснить принцип работы но я не умею писать код достаточно быстро и правильно, поэтому не берусь особо за такие работы при всем при этом мне похер, сколько денег заработает исполнитель, потому что я за свою работу беру отдельно и никак не завишу от него или от клиентки она может выбрать любого исполнителя
Ну имхо каскадный подход к разработке изжил себя еще в прошлом веке. Agile слишком неформальный. Истина, как всегда по середине. Я обычно делаю так: Собираю все требования заказчика и разбиваю проект на этапы по сроку и/или функциональности. Пропорционально этапам разбиваю и оплату. 50% стоимости этапа заказчик оплачивает перед этапом, 50% после принятия этапа. Если появляются правки в первоначальное ТЗ, требующее значительное увеличение трудозатрат, то оно идет либо как новый этап, либо изменяется существующий. Проблем стало гораздо меньше. Этакая смесь каскадного и итеративного методов
Абсолютно согласен, все проекты по waterfall сейчас не выдерживают конкуренции. Сам наблюдаю как такие проекты естественным образом перерастают в перманентный аджайл. Тот момент когда - пока согласовываем ТЗ на Ракету Илон Маск с батута запускает спутник))
@@t0digital но, должен признаться, студия была как раз из "не добросовестных". Результат соответствует указанному в договоре на разработку? Формально да. Хотите внести доработки - извольте составить на них новое ТЗ - мы оценим время и трудозатраты, выставим счет... В общем, разрабам самим надоело такое отношение руководства и мы оттуда всем отделом свалили :)
Отличный выпуск, мотивирует на подумать внимательно сначала что за тз может быть и какая возможна градация стоимости выполнения и донести уже после это до заказчика. Один в видео минус, куча рекламных роликов от ютуба попутно, я бы с удовольствием послушал нативную рекламу от автора в процессе 1 раз, желательно на тему ит, конечно :) информативность канала супер)
Всё верно, только нужно упомянуть о том что, если проект с амбициями и задачами чуть больше чем для заказчика и пары его друзей, то техническое задание это отдельная статья расходов в бюджете проекта. Ни один исполнитель в здравом уме не будет тратить свои ресурсы на "помощь" заказчику в виде составления такого документа без перспектив его окупаемости. Тем более что как правило, когда заказчику в процессе работы над ТЗ раскрываются детали проекта которые как правило меняют его представление, и часто влияют на первоначальный бюджет (в большую сторону) - большинство просто сливаются на этом этапе, а это уже прямые убытки для того исполнителя который в это вписался. Про боль отношений "исполнитель-заказчик" есть отличная короткометражка - ruclips.net/video/-EC8Q6mp8iA/видео.html
Agile действительно не самый лучший подход к случаю из реальной жизни о котором вы говорили в видео. Однако, если намерения заказчика серьезны, в его интересы должны входить дальнейшая поддержка продукта и будующие фича релизы. Agile помогает в кратчайшие сроки[1] и с минимальным бюджетом определить наиболее приоритетные реализации[2], а пет фичи оставить на потом. Как правило, потом эти пет фичи становятся ненужными, так как прибыли не приносят, а платить придется. Также заказчик на ранней стадии, потратив только часть бюджета, может определить насколько выстрелил продукт, и основываясь на этом, может решить стоит ли вкладывать остальную часть бюджета. Да и в целом, Agile это нечто внутреннее, и может быть полезен для того чтобы все разпланировать и сделать эстимейшены. P.S.: Вообще слово Agile не существительное, поэтому правильнее говорить Agility, но маркетологи и инфоцыгане исправили эту ситуацию 😁 --------------------------------- [1] - In commerce, time to market (TTM) is the length of time it takes from a product being conceived until its being available for sale. TTM is important in industries where products are outmoded quickly. A common assumption is that TTM matters most for first-of-a-kind products, but actually the leader often has the luxury of time, while the clock is clearly running for the followers en.wikipedia.org/wiki/Time_to_market [2] - A minimum viable product (MVP) is a version of a product with just enough features to satisfy early customers and provide feedback for future product development. en.wikipedia.org/wiki/Minimum_viable_product
Agile с течением времени на долгом проекте приводит к тому, что код состоит из костылей, говна и палок. Особенно тогда, когда над проектом работают в условиях постоянного прерывания и возобновления финансирования.
Нам нужно нарисовать семь красных линий. Все они должны быть строго перпендикулярны, и кроме того, некоторые нужно нарисовать зеленым цветом, а еще некоторые - прозрачным (с) Алексея очень интересно смотреть и слушать. Лично мне он очень симпатичен, как человек и специалист. С огромным удовольствием поучился бы у Алексея. Но я нищеброд, так что увы...
Извините, что не совсем по теме.. Многие из нас учатся.. У кого-то дети будут учиться. Хорошее образование многое значит для большинства. Сейчас в Украине повісили стоимость образования на 70%. Со следующего года на 80, еще через год на 90 от стоимости 2019-2020 учебного года. Основная масса студентов (стационар и заочников) учатся на контракте. И такая стоимость обучения, как предложили сейчас, для многих закроет возможности в получении образования в ВУЗах. Я еще раз извиняюсь, что не по теме, но канал образовательный и его смотрят умные люди. На сайте президента Украины есть петиция одного человека об отмене повышения цен на образование в ВУЗах страны для получения диплома бакалавра и магистра(в среднем по стране для бакалавра было 15 тыс, с этого года 25 тыс., и это только начало; для магистра дороже). Думаю, что многие понимают, что доходы населения по стране (тем более в кризис, который пока не думает прекращаться) совсем не совпадают с доходами тех депутатов и министров образования, что ввели это повышение. Прошу поддержать эту петицию (она не моя, но тема ведь актуальна для всех). И прошу распространить ссылку на эту петицию среди друзей/знакомых/неравнодушных людей к будущему наших детей да и к нашему будущему. Да, самообразование - это отлично, но получить образование в ВУЗе для человека - это должно быть хотя бы реально возможным, а не просто возможным. Вот ссылка на петицию. petition.president.gov.ua/petition/98388 Спасибо всем. И отличного всем образования и возможностей. ))
@@Maksim-nu8hb Я пытался сказать о возможностях получить образование то, что хотелось бы, а не о том, что можно и строителем быть. Интересно, смог бы стать Королёв Королёвым, если бы у него была возможность лишь поступить в ПТУ на рабочие специальности. Ведь его таланты раскрылись не в 16-18 лет, так? Его руки ведь тоже были "нужны" родине, когда лес валил.. Или Киевский политех и МВТУ у него была ли возможность закончить, когда в семье был "достаток", хотя у него еще был (учителя всё же получали стабильнее остальных). Средняя зарплата в Украине в январе 2020 года, по сравнению с декабрем 2019 года, снизилась на 1537 грн - до 10727 грн. (В различных регионах от 8000 до 15000. ) Выходит в год 120 тыс. У меня (как снимающего, и это очень не дорого) на оплату проживания около 40 тыс., на образование 30 тыс. Остаток в 50 тыс на год. При том, что 40% заработной платы (а это 35-40 тыс) уходит на питание.. Нужно что-то одеть.. Проехать на работу.. Ну и если ребенок живет в неполной семье?! Могут конечно же дети учиться и в ПТУ. И не только мои, но и Ваши. Но образование в ВУЗе - это тоже продукт на рынке. А государственное регулирование цен на образование - это какой-то нонсенс, как мне кажется. Как правило гос-во регулирует цены для того, чтобы продукт стал более доступным для большинства (не беру особые случаи на особый продукт). А в данной ситуации он стал менее доступным. Выходит, доступ к высшему образованию таким образом ограничили, оно становится доступным меньшему кол-ву, даже если очень хочется и есть способности. Не так ли?
«Без лоха и жизнь плоха». Все хотят поиметь всех, бизнес мать его. Пример с мобильным приложением зеркалит притчу с самолетом, это работает в обе стороны. Молодцы же ребята, сделали все «хочу» заказчиков и осадили их на конце чека... любой каприз за ваши деньги 😆 Смарт контракты пора вводить в моду.
Блин, ну в Agile же основное условие что беклог наполнен. Т.е. ТЗ написано. Откуда этот миф, что в agile нет ТЗ. А дальше по агилле допускаются отступания от ТЗ под изменившиеся требования, в отличие от вотерфола.
Соглашусь с agile методологиями. И добавлю ещё, особенно доставляет, когда пытаются отделы эксплуатации больших систем, состоящих из десятков, а иногда и сотен северных компонентов, тоже заставить работать по agile методикам. Мне это всё больше напоминает fragile методологии.
Не буду называть где именно, но на одной золотодобывающей компании где я работал в презентации для бенефициара была фраза: "и тогда у нас наступит ещё больший Agile", компания замечательная, но вот понимание гибкости не верное у менеджемента, вместо гибкого изменения политики в ответ на ИЗМЕНЕНИЕ ВНЕШНИХ УСЛОВИЙ (жаль нельзя подчеркнуть ещё), в компании пошли по пути метания, так тут у нас не вышло, а давайте попробуем по другому. Один из результатов такого подхода строительство транспортных съездов В ПУСТОТУ БЕЗ ЗОЛОТА на одной из шахт общей длинной 3 километра и сечением 20 метров, в деньгах несколько миллионов долларов. Так что и срам и эджайл конечно хороши, но не помешало бы ещё понимание сути подходов и необходимости их использования именно здесь и именно сейчас.
В вашем примере все сильно завязано на способности манагера доопросить заказчика до «ракеты». А что, если заказчик и манагер вообще не знают о ее существовании? Agile маленько не про то, о чем вы написали. Если перевести его на ваш проект с црм, то выходит так: вы так же собираете тз (насколько это вообще возможно). Дальше вы делаете црм и выкатываете ее заказчику. Он сразу может начать ей пользоваться. А дальше, если ничего не поменялось, вы продолжаете - делаете систему расчета зарплаты. Но в это время, црм уже «отрабатывает» деньги. В примере с црм - заказчик не знал как это называется, но точно знал чего хочет. А вот в примере с тр средством - он не знал, чего хочет. Желание не крутить педали появилось впоследствии. И это то, как реально существуют приложения. Добавляется новый функционал. Потом оно становится неповоротливым, значит, нужно все переписать, чтобы получилась машина. Главное заблуждение - что мы способны все предусмотреть и ничего не изменится.
По поводу agile, думаю, истина, как всегда где-то посередине. Широкомасштабный энтерпрайз-проект сам по себе обязан быть гибким (тут можно раскатать целую телегу о философии, стиле программирования, специальных фреймворках и полезных паттернах, но это объём нескольких книг) и , когда он уже будет внедрён в производство, работа над ним будет продолжаться в течение 10 или более лет. Никто не говорит, что ТЗ не важно, но есть случаи, когда объём этого ТЗ и время его исполнения может идти во вред проекту. Тут стоит вспомнить о минусах плановой экономики. В общем, что я хотел сказать, тут вопрос масштаба и поиска баланса (банально, но как уж есть, извините) =)
@@t0digital ну верно же Вы говорили, что стоит только время разработки. Хочет заказчик велосипед - стройте велосипед. Хочет потом самолёт - не вопрос, оплачивай следующие спритны.
Все, что не waterfall, по дурости называют agile - но по сути можно миллиард разновидностей agile построить, и каждый свою модификацию и строит, у всех свой agile, да зачастую настолько разный, что там общего-то три копейки, но всё называют гордо, эджайл
Вообще не нужно крайностей. Waterfall решает одни проблемы, agile - другие. Никто не мешает смешивать, переходить от одного к другому и обратно. На начальном этапе определяется не тз, а mvp. И это и есть цель, а не написание большого документа с распланированными сроками выполнения частей работ и оплат.
Конечно, крайностей не надо, собственно почти все и смешивают waterfall с элементами agile, но называя при этом себя до фига agile, ибо иначе не модно-молодёжно. MVP - да, иногда, но чаще заказчик хочет (и если готов заплатить, то и получает) уже более комплексное решение, чем сырой MVP, и в идеале в изначальном решении следует подумать не только об MVP, чтобы потом не приваривать крышу к велосипеду
Дело было на апворке, чувак платит 20 баксов, и просит спрарсить несколько объектов, я спрашиваю какие откуда, все дает, я спрашиваю это все что вам нужно?я буду это делать с примением этого и этого, потому то, окей начинается работа, парсер сделал, и тут правки, которые превращяют парсер в монитор, при этом так и не было доплаты, собственно проект и остался в задумке, а ебаный апворк естественно верит клиенту, они еще любят такую херь, человека не нанимают, а так он начинает работать, проект почти готов(в случае если проект маленький и быстрый) делается вид что разная тайм зона, и в итоге появляются правки, совершенно неожиданно в описании задания, П.С они появились после, и хуй веть докажешь)Вообщем предоплата, четкость 100%, сразу нужно говорить что любые правки это доп работа, так как это не входит в задачу, если адектват то сразу согласится, если нет, а ему ж вдруг нужно бует поменять цвет 5 раз то откажется.
не хочеш парсер csv написать? есть поставщик товаров, надо раз в сутки дергать этот файл, конвертить его в формат, который хочеш магазин на shopify и заливать его туда ну и еще надо датагрид, чтобы заказчик мог выбирать товар, его модели, назначать цену и это как бы было конфигом для парсера примерно такой парсер есть сервис oberlo, который импортирует товары с али через свой плагин для браузера и там потом можно выбирать только склад из европы, только размеры ххх например и назначить цену свою или умножить на 2 от цены поставщика документация по шопифаю есть в открытом доступе, возможно там надо будет раскурить апи импорта из цсв + авторизацию сразу скажу, что у заказчицы "денег нет", моюцену она не потянула и ищет кого подешевле
@@avazart614 100 баксов это мало я 1500 евров запросил там не все так просто, как я описал посмотри oberlo.com, надо такую же херню сделать, только без плагина для браузера
Я посмотрел видео и почитал комментарии. Я понял ту мысль, которую хочет донести автор видое. Но внутренне я никак не могу с этим согласиться. Пример с банками, которые пишут мелким шрифтом неудобные условия для клиента, мне кажется не очень подходящим, т.к. у банков в данном случае есть прямая цель - написать мелким шрифтом неудобные для клиета условия в надежде, что тот их не прочитает (по факту в надежде обмануть клиента). Ведь по-сути тут заказчиком является банк, т.к. он ставит условия, а исполнителем является клиент, т.к. он исполняет условия. Заказчик тот, кто ставит условия. Возьмём тогда опять гипотетический пример с банками. К примеру, банк является исполнителем и у него вообще нет никаких примеров типовых договоров по выдаче кредита. Приходит клиент/заказчик со своими условиями, сам составляет договор, который ему удобен и банк либо соглашается с условиями его договора, либо не соглашается, не предлагая ничего своего. Вся инициатива по поводу условий договора исходит всегда исключительно от клиента/заказчика. И в таком случает, если в каком-то из договоров что-то пошло не так в сторону клиента, разве можно в таком случае рассматривать условно-мошеннические действия со стороны банка? Даже если банк видел изначально, что условия не в пользу клиента/заказчика, но эти условия сам клиент/заказчик по своей инициативе предложил, сам их придумал, сам пришёл, сам предложил и настаивал может даже возможно. Я, к примеру, вообще не разбираюсь в строительстве и ремонте. У меня на даче дом кирпичный. У него трескается стена. Я изучил довольно много материала по этому поводу, и пришёл к выводу, что это происходит из-за того, что не совсем правильно был сделан фундамент при его строительстве до того, как мы купили дачу. Я сам трачу несколько недель, чтобы изуить этот вопрос досконально, погрузиться в строительную тематику, понять, какие наиболее эффективные решения существуют для этой задачи, 50 раз проконсультируюсь с тем, кто уже столкунлся с этим. И только потом выберу способ, которым буду решать этот вопрос, найму людей, которым дам чёткие инструкции, что конкретно мне нужно сделать (возможно, даже сам приобрету материалы для ремонта). И если после ремонта через какой-то период у меня дом на даче развалится, я никого ни в чём винить не буду. Я сам всё изучил и принял решение. И того же самого ожидаю от всех остальных!
Почему мелкий щрифт обязательно обмануть? Можно мелким шрифтом указать, что велосипед не переделывается в мопед, нн оснащается коляской, крышей, не трансформируется в ракету. И иногда это выход, когда контрагент не хочет в основной части договора ввести понятие велосипед - двухколесное транспортное средство, движимое мускульной силой человека, прилагаемой ногами на педали, сидение анатомической формы, управляется ручным рулем. Тормоза такие-то.
У заказчика есть деньги, он хочет, и даже стремится приобрести опыт, не редко печальный получается. Так бывает и на бытовом уровне, в жизни. Я проектировал и на старте, и на этапе, когда архитектура была заложена ранее. Но, почти всегда работаю "по гибкому". Есть и успешные велосипеды-ракеты, как то летают криво-косо, что то пробуют (в смысле идеи), идёт - продолжают, не идёт - бросают. Не знать, чего хотеть - это нормально. А сам я разработчик, не маркетолог, не специалист по бизнесу. Кто его знает, как пойдёт бизнес, нужна будет завтра ракета, а мы велик сделали, или сделали ракету, которая нафиг не нужна. Ну и естественно - резиновое тз = резиновый бюджет. С другой стороны, я строю дом, и, как инжинер - хорошо, что додумался заказать проект, и пропогандирую это среди друзей. Но есть много людей, у кого нет возможности вкладываться в проекты, предварительные оценки, но есть желание сыграть в судьбу - их право. В общем, как всегда, оба подхода имею право на жизнь, раз они есть.
@@t0digital а то, что твой подход работает когда ты тратишь чужие деньги, заказчика. и риски постройки ракеты перекладываешь на него, и страхуешь свою ответственность. можно нанять аналитиков, техписателей, разрабов, тестеров, дивопскоманду, и рабтать работать работать, пока платить будут. сначала пишешь тз полгода , потом его согласовываешь, потом пишешь этапы, их согласовываешь, потом вносишь изменения в тз, опять согласовываешь, и все строишь и строишь свою ракету. желательно еще договор так составить чтобы заказчик не мог отказаться от твоих услуг без штрафов. результата все нет, когда спрашивают про результат - тыкаешь его в тз, которое или слишком общее чтобы его реализовать, наинаешь его уточнять - оно начинает противоречить разным своим частям, потому что результат- это всегда компромис, и это дает тебе возможность еще увеличивать стоимость проекта , не давая никакого результата. а если все таки заказчик дожмет, и пригрозит судом - можешь выкатывать ему устаревшую на годы реализацию, неопробованную, без фитбека. и ни дай бог он попросит что-то добавить или переделать. ты конечно скажешь - нет нет нет "НЕ ПО ТЗ" , тут проще все переделать с нуля)) так что когда мои знакомые хотят потратить все свои деньги на "самолет" - я говорю - закажи сначала велосипед. проверь. попробуй. отбей затраты. полетит - прикрутим мотор достоинства: есть сразу результат. есть обратная связь. потому что сам заказчик может не знать, что ему нужно. никто не может этого знать точно, и только в процессе развития проекта он понимает что ему нужно, а что нет. Канал классный,
И неплохо было бы, чтобы заказчик (по возможности) указал на подобие того, чего он хочет. Например, хочу SAP, но дешевле и понятней. А, тогда вот вам 1С.
Таких заказчиков - чудаков на букву "М" - 70% Заказчик сам не понимает чего хочет. Но где-то-слышал пару умных слов, а у друзей/конкурентов есть, и мне нужно. Даже не касаясь программирования. В любом другом направлении - важно ТЗ. И на ТЗ бывает уходит больше времени чем на саму работу/разработку
Я Вам сбрасывал предложения по поводу приложения для мобильных устройств (телефонов). И, увы, не услышал вашего ответа, мнения. Хотел бы, если возможно, понять вашу реакцию на мою идею. Спасибо
Не совсем согласен,естественно заказчик может не знать разницу между велосипедом,автомобилем,самолетом,но знать чего он хочет исполнитель не то что не обязан ,но и не может.Может же заказчик различать свои желания?))))Он хочет ,чтобы его транспорт ездил ,летал, спал или кофе ему ставил знать то должен.Не нужно заказчику технически объяснять свой заказ,но перед заказом можно немного,совсем чуток исследовать область и его возможности,на основании этого сформировать свои желания и на человеческом языке преподнести свой заказ
-А как же новомодная тенденция на коленке слабать MVP, а затем скрамными спринтами желательно вечно допиливать его валюе до кастомерских реквайрементов и кондишенов- Хи-хи, поспешил.
чувствуется что agile воспринимается как серебряная пуля, но это не так. Уметь им пользоваться, иметь соответсвующий уровень зрелости как команды так и Заказчика - тогда он полезен, и более результативен чем "водопад". Работал много и долго по "водопаду" и Agile, как в больших так и в маленьких командах, И как итог, к "водопаду" возвращаться не хочется.
В целом - видео интересное.. Но с "Agile" вы абсолютно не правы. "Agile" про другое... Agile - это подход к разработке программного обеспечения, и определяется Agile Manifesto. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются команды. Agile Manifesto: - Люди и взаимодействие важнее процессов и инструментов - Работающий продукт важнее исчерпывающей документации - Сотрудничество с заказчиком важнее согласования условий контракта - Готовность к изменениям важнее следования первоначальному плану То есть, не отрицая важности того, что справа, всё-таки больше ценится то, что слева...
Интересно, к чему здесь был приведен agile? Методология, очевидно, не подходит для больших проектов. Но в целом, и для больших проектов ее можно использовать, приняв все ее риски (дерьмовая кодовая база и отсутствие спланированной архитектуры либо ее монолитность), которые впоследствии повлекут за собой огромные издержки, примером которых, наверное, является ваш разсказ с мобильным приложением. Мне кажется, что с хорошим опытом, руководитель команды должен понимать, что за проект перед ними предстал. Оценить самого заказчика, оценить масштабы его бизнеса, проговорить все детали, после чего уже начать разработку, выбрав правильную, по его мнению, методологию. И agile не говорит о том, что ТЗ нам нафиг не нужно, она говорит о том, что нужно быть всегда готовым к изменениям и стараться писать не монолиты, оставлять возможности для подключения модулей и т.д., ТЗ в ней не отсутствует, оно совсем небольшое, расчитаное только на работоспособность чего-то конкретного, без оценки дальнейших возможных путей развития этого чего-то, что потом и встает боком. Но все же, повторюсь, для мелких проектов, методология годная и экономит время, ин май опинион, конечно же)
@@avazart614 Две сотни раз! Тратить 70% рабочего времени на подтирание соплей заказчику. Супер бизнес схема. Я понимаю что есть откровенные мудаки, но есть и откровенные мозго... ли заказчики.
не согласен с мнением, что в описываемой ситуации вина лежит на заказчике. В данной ситуации оба хороши - если заказываешь нечто уникальное, то должен чётко понимать что ты хочешь получить в итоге.
Если вы формошлепская студия -- вам не нужен эджаил, если вы продуктовая компания, которая находится в активной стадии дискавери, то удачи вам с четким планом )
В видео речь о заказчике и исполнителе, что подразумевает заказную разработку. И нет, заказная разработка это не обязательно формошлепство, равно как и продуктовая нередко бывает классическим формошлепством
Диджитализируй! Меня скорее возмутил тон повествования о людях которые видят смысл в эджайл, поэтому я быканул и употребил термин формошлепство, в общем, зря.
Привет, спасибо .... очень важная тема, жаль только что довольно мало её так видят. Даже если уже пролетали и строили ракету по цене велосипеда не учатся на своих ошибках. Я работаю в большой компании в Германии и сталкиваюсь с этой проблемой каждый день. В своём блоке тоже уже писал статью на эту тему ... заходите буду рад пообщаться www.iot-architect.de/requirements-engineering-superpower-of-a-system-architect
Опыт учит выявлять таких заказчиков на этапе написания ТЗ и отказываться от дальнейшей работы с ними. По этапу разработки ТЗ и заказчик может узнать исполнителя, и исполнитель - заказчика.
Есть такое понятие как социальная адаптированость и наличие 2ой сигнальной системы, которую господь бог дал вам в процессе эволюции вида хомо сапиенс )))) или просто сознайтесь в том что Вам лень разговаривать с заказчиком ))))
Потому что нужно продать, а не сдать...много фирм не понимают, что сдавать тоже нужно, а многие умеют так уходить от судов, что им и не нужно париться...главное - получить предоплату
Не скажу куда гляжу, принесу то не знаю что . . . История о том, как встретились 2 фантазера и у обоих нет нет понимания что ОНИ хотят получить на выходе к первому (так скажем) числу ! Есть старая пословица или поговорка о том, что все надо решать на берегу . Ибо НеХ...й
Есть еще просто идиоты, которые хотят сами не знают чего. Был у меня случай. заказали калькулятор на сайт, сделал, вроде понравилось. Через какое-то время обратились за консультацией по сайту (их фирма мурыжила больше года и никак не заканчивала работу) Я рассказал. в итоге они меня просят сделать. Я им план накидал и все прочее. В итоге они хотели чтобы я за деньги котоыре уже заплачены другим сделал им новый сайт с нуля. В общем отправился такой заказчик в пеший тур по известному адресу.
Все просто - пишем велосипед, облепляем его тестами с головы до ног, а лучше тесты а потом велосипед. Потом пишем тест, чтоб велик перелетел через реку. Нифига он не прошёл, мастырим реактивную тягу к велику, тестируем - зашибись! Ну это в идеале ) А так, бывал я на проекте с ТЗ, которое окаменело с момента создания. Проект вообще ушёл хрен знает куда, тесты стали заваливаться, времени на их починку нехватало, новые тесты тоже не писались, ну или абы как писались, и проект потихонечку стал попахивать тухлятиной. Потом стали-таки ПМ-ы лепить какие-то ТЗ абсолютно не понимая как проект работает, но это все равно что ставить ТЗ на увеличение максимальной скорости автомобиля, тогда как двиган у него троит, коробка скоро уйдёт на тот свет, а колеса проколоты, а времени это все починить хер кто выделит, клиентам нужны фичи )))
Поймал негр золотую рыбку.
- Отпусти меня, - говорит золотая рыбка, - Любое твое желание исполню.
Подумал негр и говорит:
- Сделай меня белым, и чтобы вокруг меня одни женщины были. Махнула рыбка хвостом… и превратила негра в унитаз в женском туалете.
Будьте аккуратны с ТЗ
хахаха, это прекрасно)))
@@t0digital Зависть - грех!
@@t0digital Не завидуйте негру. Шютка.
Осудительный комментарий! (одобряю)
Вот я всегда мечтал иметь такое видео, которое можно просто скинуть вместо объяснения того с кем приходится работать) от души ♥
Озвучил мою мысль- покажу своему директору. А то он специалистов меняет как перчатки и все у него дебилы.
а тебе ответят "нахуя вы мне видео какие-то скидываете, вы можете работу свою сделать просто????"
Лайк в надежде, что максимальное кол-во заказчиков увидят это
Кажется от вас ускользнула основная мысль видео - что задача доносить важность ТЗ лежит на нас как исполнителях.
шикарно, первая часть видео - маленький шедевр, теперь нет ни нотки сомнений в этапе составления тз, даже для маленьких проектов
Буду заказчикам скидывать эту притчу.) Спасибо!
Аж фильм "войны Пентагона" вспомнился))) советую посмотреть всем чтобы темой проникнуться, особенно для работы с компаниями с большим административным ресурсом
Совершенно! Буду знать куда заказчиков -посылать- направлять.
отлично:)!
Спасибо, очень толково и по делу. Стал лучше понимать, чем мой работодатель занимается))
В начале фриланс пути я сильно обжёгся на моменте с ТЗ. Пришла задача от хорошего знакомого, о чьих технических навыках я был хорошего мнения. ТЗ выглядело продуманным и подробным. Я проявил невнимательность, взял заказ и начал прорабатывать. По ходу дела оказалось, что в ТЗ много дыр, белых пятен и противоречащих друг другу пунктов. Разработка из-за этого усложнилась в геометрической прогрессии и необходимый бюджет сильно возрастал. В тот момент, попробовав объяснить специфику усложнения задачи, я слился с заказа. С тех пор если я вижу, что у заказа есть намёки на творческую сложность - я предлагаю проработку мной технического ТЗ как предварительную услугу. Если итоговое ТЗ для меня исполнимо - то делаем. Если нет - простите.
Ставлю лайк, за подачу и поднятие самой проблемы, но с автором во многом согласен и во многом не согласен одновременно. Занимаюсь разработками/доработками CRM систем уже более 5 лет, участвовал за это время в десятках проектов и поэтому считаю, что могу высказать и обосновать свое мнение. ТЗ это конечно хорошо в целом, тут полностью согласен, но бывает так, что разработать полностью детальное ТЗ, в котором бы были учтены все нюансы и детали, просто не возможно... У меня был негативные случай, когда разработкой ТЗ занималась целая проектная команда из PM, нескольких аналитиков и разработчиков (в качестве экспертов) на протяжении примерно полугода. Получился документ примерно в 1 тыс. страниц. Был потрачен почти месяц на детальную оценку, т.к. заказчик хотел знать заранее "сколько каждая кнопочка стоит в граммах". И в результате ничего! Заказчик остался недоволен потраченному времени и оценке (слишком дорого, они хотели все и за копейку), а я лично, как разработчик, полугодом потерянным на пустую писанину. Другой, тоже крупный проект, разработано и утверждено детальное ТЗ. Делаем первый этап четко по ТЗ, а заказчик говорит, что принимать и оплачивать работы не будет, т.к. он видел все по другому, а на ТЗ ему плевать и мы можем им подтереться... Еще пример, на этот раз позитивный, заказчик просит сделать доработки в CRM для внедрения собственной системы электронного документооборота и сбрасывает ТЗ (ну, почти ТЗ, скорее набор требований), которое очень похоже на документацию для Lotus Notes. В результате мастерски проведенных переговоров, договариваемся о разумном бюджете на квартал и работе в режиме T&M с еженедельными релизами. Через месяц заказчик полностью доволен доработкой документооборота, хотя мы сделали от силы 3% от изначальных требований. Оказывается именно это и в таком объеме ему и было нужно (сам он об этом в начале проекта даже на знал). Потом мы с этим заказчиком в таком же режиме работали несколько лет и все были довольны. А что было бы если бы мы на месяц другой ушли и стали разрабатывать полное ТЗ?
В общем итог такой. ТЗ действительно нужно, но если не получается сделать его быстро и небольшого объема, то нужно договариваться на релизы, оговаривать объем работ (деньги) делать небольшое, но понятное ТЗ на один ближайший релиз и начинать делать и сразу показывать заказчику результаты, давая при этом вносить любые изменения, которые "влезают" в обговоренный скоуп работ. И тогда пример с велосипедом-ракетой не был бы такой страшный. Возможно еще при установке колес на велосипед выяснилось, что их должно быть 4ре, а не 2а. А когда дошли до автомобиля, то просто озвученная стоимость работ следующего этапа, заставила бы заказчика остановиться... Так у меня кстати было и не раз, когда "раздувающиеся" требования от бизнес-заказчика, жестко отвергались PM со стороны заказчика с формулировкой денег на такие "рюшки" нет.
В точку! Вспомнил про «прозрачную красную линию в форме котёнка». А по Agile, я думаю что для сложных проектов с хорошими требованиями к надежности нужен waterfall или подобные методологии, для быстрой разработки для создания MVP, нужны агилы. А вот ТЗ надо всем;)) ТЗ это как нарисовать мишень, есть понимание куда стрелять. Спасибо за видос!
Имхо какие-то вещи из agile разумны и работают, например, начинать проект с самого важного функционала системы, а затем по ходу проекта иметь возможность выкинуть что-то из менее важного, заменив его более важным, даже не входящим в изначальное ТЗ, но имеющим схожую трудоёмкость реализации. Система оценки задач внутри проекта по баллам интересна и вполне может использоваться. Но штука в том, что это всего лишь некоторые инструменты из большой agile методологии, то есть использование их это не есть использование agile в чистом виде:) Гибкости это добавляет, но не в том объёме, как заявляют приверженцы полностью гибких методологий
Согласен насчет необходимости ТЗ, но вот насчет сложности проектов разрешите вставить 5 копеек.)
Agile как раз был придуман для мегасложного проекта, который несколько раз пытались сделать по ватерфоллу, но не получалось, потому что проект каждый раз делали так долго, что представления заказчиков или сама реальность банально успевали измениться (это была какая-то система для ФБР, которую делали в 1980-1990 гг. и наконец-то сделали в 1993 году, параллельно изобретя аджайл).
Наличие изначальных требований к безопасности и надежности продукта никак аджайлу не противоречит. Идея аджайла скорее в том, чтобы заставить заказчика и исполнителя чаще друг с другом коммуницировать и в процессе этой коммуникации уточнить все требования, которые заказчик забыл указать в изначальном ТЗ и реализацию которых не заложили в вотерфоле (ну и новых требований, которые появились уже в процессе работы над проектом, после подписания ТЗ).
@@t0digital Просто истина, всегда где-то посередине: например в СССР проработка ТЗ занимала намного больше, времени и иногда доходила до абсурда. Та же лунная база, разработка тз которой заняла более 10 лет, а итогом встал вопрос о невозможности все профинансировать, или была шахта, которую построили вроде за год, а разработка тз длилась 20 лет.
В то же время сейчас пошла мода на абстрактные проекты, которые невозможно сдать и невозможно принять.
@@Kolinsinks27332 Так в этом же и есть смысл идеологии! Agile - это не методичка, а образ действий/мыслей.
4:49 - а почему лапки исполнителя, а не лапки заказчика (и 300 т. в зубах)?
вспомнил себя в последнем проекте
Из моего личного опыта. Заказчик очень часто, особенно в небольших лавках, сам не представляет что и как. Фраза после которой я обычно посылаю заказчика - "Ну сделайте как-нибудь". Понял что ничего хорошего с такими заказчиками не получится.
Заказчик действительно часто многое не понимает в той сфере, в которой нанимает исполнителя - но это и нормально, для того спецы и нужны, которые рубят в своей теме и помогают тем, кто в этой теме не рубит. Адекватные заказчики прислушиваются к разумным доводам исполнителя о том, как всё стоит сделать. А с неадекватными работать не стоит:)
@@t0digital Аминь!
Лол, ты прав. Для этого и нужны, прости господи, маркетологи и сейлы, чтобы в такой ситуации убедить заказчика, что для него сделано не просто какое-то г. с синхронизацией на слипах, а революционный передовой продукт, красоте и совершенству которого нет предела.
@@Ronin34rus
для этого нужен независимый технический консультант
такой человек может объяснять сложные вещи понятным языком и по сути является интерфейсом между заказчиком и исполнителем
например есть у меня клиентка и она говорит на русском, но у нее магазин на немецком и связан с немецким поставщиком по европам
у поставщика дока на их формат данных на немецком и русскоговорящие дешевые фрилансеры не берутся за эту работу, потому что не знают немецкого и не знают, чего хочет тетка
а я знаю чего она хочет, чего ей надо сделать, чего надо сделать исполнителю, как это надо сделать и могу перевести доку на русский и нарисовать интерфейс и объяснить принцип работы
но я не умею писать код достаточно быстро и правильно, поэтому не берусь особо за такие работы
при всем при этом мне похер, сколько денег заработает исполнитель, потому что я за свою работу беру отдельно и никак не завишу от него или от клиентки
она может выбрать любого исполнителя
Посмотрел с удовольствием!
четко ясно всё объяснил.
А что насчёт создания быстрого прототипа системы?
На котором уже будет досканально уточняться ТЗ.
На каких масштабах такое работает?
Спасибо за видосы. Ты единственный, кого я смотрю в обычной скорости, а не в х2
Спасибооо!
Спасибо, отличный вариант
В итоге: Нужно утвержденное и согласованное ТЗ. Если внезапно, на середине проекта, просят из велосипеда сделать баржу, вежливо тыкаем в ТЗ.
Да!
Агонь, а в усім проблеми ніби в набраних аналітиків, а на справді в їх відсутності зі сторони замовника. Повністю згоден!
Ну имхо каскадный подход к разработке изжил себя еще в прошлом веке. Agile слишком неформальный. Истина, как всегда по середине.
Я обычно делаю так: Собираю все требования заказчика и разбиваю проект на этапы по сроку и/или функциональности. Пропорционально этапам разбиваю и оплату. 50% стоимости этапа заказчик оплачивает перед этапом, 50% после принятия этапа. Если появляются правки в первоначальное ТЗ, требующее значительное увеличение трудозатрат, то оно идет либо как новый этап, либо изменяется существующий. Проблем стало гораздо меньше.
Этакая смесь каскадного и итеративного методов
Абсолютно согласен, все проекты по waterfall сейчас не выдерживают конкуренции. Сам наблюдаю как такие проекты естественным образом перерастают в перманентный аджайл. Тот момент когда - пока согласовываем ТЗ на Ракету Илон Маск с батута запускает спутник))
RESPECT, ну чувак прям мои мысли в слух 😀
Как точно описал мою уже бывшую работу в веб-студии 🤣
Понимаю :)
@@t0digital но, должен признаться, студия была как раз из "не добросовестных". Результат соответствует указанному в договоре на разработку? Формально да. Хотите внести доработки - извольте составить на них новое ТЗ - мы оценим время и трудозатраты, выставим счет... В общем, разрабам самим надоело такое отношение руководства и мы оттуда всем отделом свалили :)
Отличный выпуск, мотивирует на подумать внимательно сначала что за тз может быть и какая возможна градация стоимости выполнения и донести уже после это до заказчика. Один в видео минус, куча рекламных роликов от ютуба попутно, я бы с удовольствием послушал нативную рекламу от автора в процессе 1 раз, желательно на тему ит, конечно :) информативность канала супер)
"Без ТЗ результат ХЗ" - взял себе на вооружение! Огонь!
Всё верно, только нужно упомянуть о том что, если проект с амбициями и задачами чуть больше чем для заказчика и пары его друзей, то техническое задание это отдельная статья расходов в бюджете проекта.
Ни один исполнитель в здравом уме не будет тратить свои ресурсы на "помощь" заказчику в виде составления такого документа без перспектив его окупаемости. Тем более что как правило, когда заказчику в процессе работы над ТЗ раскрываются детали проекта которые как правило меняют его представление, и часто влияют на первоначальный бюджет (в большую сторону) - большинство просто сливаются на этом этапе, а это уже прямые убытки для того исполнителя который в это вписался.
Про боль отношений "исполнитель-заказчик" есть отличная короткометражка - ruclips.net/video/-EC8Q6mp8iA/видео.html
Agile действительно не самый лучший подход к случаю из реальной жизни о котором вы говорили в видео. Однако, если намерения заказчика серьезны, в его интересы должны входить дальнейшая поддержка продукта и будующие фича релизы.
Agile помогает в кратчайшие сроки[1] и с минимальным бюджетом определить наиболее приоритетные реализации[2], а пет фичи оставить на потом. Как правило, потом эти пет фичи становятся ненужными, так как прибыли не приносят, а платить придется. Также заказчик на ранней стадии, потратив только часть бюджета, может определить насколько выстрелил продукт, и основываясь на этом, может решить стоит ли вкладывать остальную часть бюджета. Да и в целом, Agile это нечто внутреннее, и может быть полезен для того чтобы все разпланировать и сделать эстимейшены.
P.S.: Вообще слово Agile не существительное, поэтому правильнее говорить Agility, но маркетологи и инфоцыгане исправили эту ситуацию 😁
---------------------------------
[1] - In commerce, time to market (TTM) is the length of time it takes from a product being conceived until its being available for sale. TTM is important in industries where products are outmoded quickly. A common assumption is that TTM matters most for first-of-a-kind products, but actually the leader often has the luxury of time, while the clock is clearly running for the followers
en.wikipedia.org/wiki/Time_to_market
[2] - A minimum viable product (MVP) is a version of a product with just enough features to satisfy early customers and provide feedback for future product development.
en.wikipedia.org/wiki/Minimum_viable_product
Agile с течением времени на долгом проекте приводит к тому, что код состоит из костылей, говна и палок. Особенно тогда, когда над проектом работают в условиях постоянного прерывания и возобновления финансирования.
у нас был проект с тех задание на 18 листов, работала 16 програмеров 18 месецев :D
Очень жизненно. Отправил ссылку на видео начальнику.
Нам нужно нарисовать семь красных линий. Все они должны быть строго перпендикулярны, и кроме того, некоторые нужно нарисовать зеленым цветом, а еще некоторые - прозрачным (с)
Алексея очень интересно смотреть и слушать. Лично мне он очень симпатичен, как человек и специалист.
С огромным удовольствием поучился бы у Алексея. Но я нищеброд, так что увы...
А ещё, пусть одна будет в виде котёнка. :)
Будет видео по agile/scrum?
Возможно:)
Извините, что не совсем по теме.. Многие из нас учатся.. У кого-то дети будут учиться. Хорошее образование многое значит для большинства.
Сейчас в Украине повісили стоимость образования на 70%. Со следующего года на 80, еще через год на 90 от стоимости 2019-2020 учебного года.
Основная масса студентов (стационар и заочников) учатся на контракте. И такая стоимость обучения, как предложили сейчас, для многих закроет возможности в получении образования в ВУЗах.
Я еще раз извиняюсь, что не по теме, но канал образовательный и его смотрят умные люди. На сайте президента Украины есть петиция одного человека об отмене повышения цен на образование в ВУЗах страны для получения диплома бакалавра и магистра(в среднем по стране для бакалавра было 15 тыс, с этого года 25 тыс., и это только начало; для магистра дороже).
Думаю, что многие понимают, что доходы населения по стране (тем более в кризис, который пока не думает прекращаться) совсем не совпадают с доходами тех депутатов и министров образования, что ввели это повышение.
Прошу поддержать эту петицию (она не моя, но тема ведь актуальна для всех). И прошу распространить ссылку на эту петицию среди друзей/знакомых/неравнодушных людей к будущему наших детей да и к нашему будущему.
Да, самообразование - это отлично, но получить образование в ВУЗе для человека - это должно быть хотя бы реально возможным, а не просто возможным.
Вот ссылка на петицию. petition.president.gov.ua/petition/98388
Спасибо всем. И отличного всем образования и возможностей. ))
@@Maksim-nu8hb Я пытался сказать о возможностях получить образование то, что хотелось бы, а не о том, что можно и строителем быть.
Интересно, смог бы стать Королёв Королёвым, если бы у него была возможность лишь поступить в ПТУ на рабочие специальности. Ведь его таланты раскрылись не в 16-18 лет, так? Его руки ведь тоже были "нужны" родине, когда лес валил.. Или Киевский политех и МВТУ у него была ли возможность закончить, когда в семье был "достаток", хотя у него еще был (учителя всё же получали стабильнее остальных).
Средняя зарплата в Украине в январе 2020 года, по сравнению с декабрем 2019 года, снизилась на 1537 грн - до 10727 грн. (В различных регионах от 8000 до 15000. )
Выходит в год 120 тыс. У меня (как снимающего, и это очень не дорого) на оплату проживания около 40 тыс., на образование 30 тыс. Остаток в 50 тыс на год. При том, что 40% заработной платы (а это 35-40 тыс) уходит на питание.. Нужно что-то одеть.. Проехать на работу.. Ну и если ребенок живет в неполной семье?!
Могут конечно же дети учиться и в ПТУ. И не только мои, но и Ваши.
Но образование в ВУЗе - это тоже продукт на рынке. А государственное регулирование цен на образование - это какой-то нонсенс, как мне кажется. Как правило гос-во регулирует цены для того, чтобы продукт стал более доступным для большинства (не беру особые случаи на особый продукт). А в данной ситуации он стал менее доступным.
Выходит, доступ к высшему образованию таким образом ограничили, оно становится доступным меньшему кол-ву, даже если очень хочется и есть способности. Не так ли?
Отличное видео!
«Без лоха и жизнь плоха». Все хотят поиметь всех, бизнес мать его.
Пример с мобильным приложением зеркалит притчу с самолетом, это работает в обе стороны. Молодцы же ребята, сделали все «хочу» заказчиков и осадили их на конце чека... любой каприз за ваши деньги 😆
Смарт контракты пора вводить в моду.
Недели разработки экономят часы планирования
Полностью поддерживаю изложенные тут мысли. Успел сам с таким столкнуться (Ну, слава богу, не так болезненно, как из лесопеда в ракету)
Добросовестный исполнительно должен подключиться к космосу и дописать ТЗ!
а чем PPDIOO от AGILE отличается
Спасибо.
Поучительно
Спасибо, как всегда меджик)
когда уже порадуете кодревью?)
Автофокус шикарен
ах вот оно что такое аджайл. Куча методологий имею какие-то крайне похожие определения, а в итоге все сводится к аджайлу
Блин, ну в Agile же основное условие что беклог наполнен. Т.е. ТЗ написано. Откуда этот миф, что в agile нет ТЗ. А дальше по агилле допускаются отступания от ТЗ под изменившиеся требования, в отличие от вотерфола.
Так то в водопаде в тз тоже можно изменения вносить
Соглашусь с agile методологиями. И добавлю ещё, особенно доставляет, когда пытаются отделы эксплуатации больших систем, состоящих из десятков, а иногда и сотен северных компонентов, тоже заставить работать по agile методикам. Мне это всё больше напоминает fragile методологии.
Не буду называть где именно, но на одной золотодобывающей компании где я работал в презентации для бенефициара была фраза: "и тогда у нас наступит ещё больший Agile", компания замечательная, но вот понимание гибкости не верное у менеджемента, вместо гибкого изменения политики в ответ на ИЗМЕНЕНИЕ ВНЕШНИХ УСЛОВИЙ (жаль нельзя подчеркнуть ещё), в компании пошли по пути метания, так тут у нас не вышло, а давайте попробуем по другому. Один из результатов такого подхода строительство транспортных съездов В ПУСТОТУ БЕЗ ЗОЛОТА на одной из шахт общей длинной 3 километра и сечением 20 метров, в деньгах несколько миллионов долларов. Так что и срам и эджайл конечно хороши, но не помешало бы ещё понимание сути подходов и необходимости их использования именно здесь и именно сейчас.
В вашем примере все сильно завязано на способности манагера доопросить заказчика до «ракеты». А что, если заказчик и манагер вообще не знают о ее существовании?
Agile маленько не про то, о чем вы написали. Если перевести его на ваш проект с црм, то выходит так: вы так же собираете тз (насколько это вообще возможно). Дальше вы делаете црм и выкатываете ее заказчику. Он сразу может начать ей пользоваться. А дальше, если ничего не поменялось, вы продолжаете - делаете систему расчета зарплаты. Но в это время, црм уже «отрабатывает» деньги.
В примере с црм - заказчик не знал как это называется, но точно знал чего хочет. А вот в примере с тр средством - он не знал, чего хочет. Желание не крутить педали появилось впоследствии. И это то, как реально существуют приложения. Добавляется новый функционал. Потом оно становится неповоротливым, значит, нужно все переписать, чтобы получилась машина.
Главное заблуждение - что мы способны все предусмотреть и ничего не изменится.
Ну почему же, Agile прекрасен, если заказчик не стеснен бюджетом. ) Иногда они попадаются
С чего вы решили, что заказчик не стеснен бюджетом?
Все умеют считать деньги, и заказчик не исключение!..
Евгений Романов из личного опыта.
Очень интересное и как бывает иногда - правдивое, меня даже взбесил этот заказчик немного :)
3:11 "включает Тони Старка"-хехе))
По поводу agile, думаю, истина, как всегда где-то посередине.
Широкомасштабный энтерпрайз-проект сам по себе обязан быть гибким (тут можно раскатать целую телегу о философии, стиле программирования, специальных фреймворках и полезных паттернах, но это объём нескольких книг) и , когда он уже будет внедрён в производство, работа над ним будет продолжаться в течение 10 или более лет. Никто не говорит, что ТЗ не важно, но есть случаи, когда объём этого ТЗ и время его исполнения может идти во вред проекту. Тут стоит вспомнить о минусах плановой экономики.
В общем, что я хотел сказать, тут вопрос масштаба и поиска баланса (банально, но как уж есть, извините) =)
гибкие методологии Вы не приветствуете, как я понял?
приветствую, просто не бездумное копирование, а с включением головы:)
@@t0digital ну верно же Вы говорили, что стоит только время разработки. Хочет заказчик велосипед - стройте велосипед. Хочет потом самолёт - не вопрос, оплачивай следующие спритны.
Заказчики это ведь такие же люди, как и мы с вами, нормальные - с понятным желанием не выбрасывать деньги на ветер.
Амазон, Paypal и Gett как-то работают по agile, и всё даже работает
Все, что не waterfall, по дурости называют agile - но по сути можно миллиард разновидностей agile построить, и каждый свою модификацию и строит, у всех свой agile, да зачастую настолько разный, что там общего-то три копейки, но всё называют гордо, эджайл
@@t0digital Какая разница что там внутри, люди работают двухнедельными спринтами, без многомесячных ТЗ
@@MMEEEish наличие 2х-недельных спринтов не делают компанию agile. Отсутствие ТЗ и подавно
@@t0digital вы в какую-то другую сторону поехали, я вам про то что без подробного ТЗ работают, а вы мне про то что такое Agile
Вообще не нужно крайностей. Waterfall решает одни проблемы, agile - другие. Никто не мешает смешивать, переходить от одного к другому и обратно. На начальном этапе определяется не тз, а mvp. И это и есть цель, а не написание большого документа с распланированными сроками выполнения частей работ и оплат.
Конечно, крайностей не надо, собственно почти все и смешивают waterfall с элементами agile, но называя при этом себя до фига agile, ибо иначе не модно-молодёжно. MVP - да, иногда, но чаще заказчик хочет (и если готов заплатить, то и получает) уже более комплексное решение, чем сырой MVP, и в идеале в изначальном решении следует подумать не только об MVP, чтобы потом не приваривать крышу к велосипеду
Дело было на апворке, чувак платит 20 баксов, и просит спрарсить несколько объектов, я спрашиваю какие откуда, все дает, я спрашиваю это все что вам нужно?я буду это делать с примением этого и этого, потому то, окей начинается работа, парсер сделал, и тут правки, которые превращяют парсер в монитор, при этом так и не было доплаты, собственно проект и остался в задумке, а ебаный апворк естественно верит клиенту, они еще любят такую херь, человека не нанимают, а так он начинает работать, проект почти готов(в случае если проект маленький и быстрый) делается вид что разная тайм зона, и в итоге появляются правки, совершенно неожиданно в описании задания, П.С они появились после, и хуй веть докажешь)Вообщем предоплата, четкость 100%, сразу нужно говорить что любые правки это доп работа, так как это не входит в задачу, если адектват то сразу согласится, если нет, а ему ж вдруг нужно бует поменять цвет 5 раз то откажется.
не хочеш парсер csv написать?
есть поставщик товаров, надо раз в сутки дергать этот файл, конвертить его в формат, который хочеш магазин на shopify и заливать его туда
ну и еще надо датагрид, чтобы заказчик мог выбирать товар, его модели, назначать цену и это как бы было конфигом для парсера
примерно такой парсер есть сервис oberlo, который импортирует товары с али через свой плагин для браузера и там потом можно выбирать только склад из европы, только размеры ххх например и назначить цену свою или умножить на 2 от цены поставщика
документация по шопифаю есть в открытом доступе, возможно там надо будет раскурить апи импорта из цсв + авторизацию
сразу скажу, что у заказчицы "денег нет", моюцену она не потянула и ищет кого подешевле
@@kalobyte могу сделать, напишешь на почту? r0tt3n-m3m0ry@protonmail.com
@@cupofcode1170
да пока не надо
я сейчас купил пхп курс и учусь, сам напишу
@@avazart614
100 баксов это мало
я 1500 евров запросил
там не все так просто, как я описал
посмотри oberlo.com, надо такую же херню сделать, только без плагина для браузера
@@kalobyte я бы за 500 такое сделал..
Я посмотрел видео и почитал комментарии. Я понял ту мысль, которую хочет донести автор видое. Но внутренне я никак не могу с этим согласиться. Пример с банками, которые пишут мелким шрифтом неудобные условия для клиента, мне кажется не очень подходящим, т.к. у банков в данном случае есть прямая цель - написать мелким шрифтом неудобные для клиета условия в надежде, что тот их не прочитает (по факту в надежде обмануть клиента). Ведь по-сути тут заказчиком является банк, т.к. он ставит условия, а исполнителем является клиент, т.к. он исполняет условия. Заказчик тот, кто ставит условия.
Возьмём тогда опять гипотетический пример с банками. К примеру, банк является исполнителем и у него вообще нет никаких примеров типовых договоров по выдаче кредита. Приходит клиент/заказчик со своими условиями, сам составляет договор, который ему удобен и банк либо соглашается с условиями его договора, либо не соглашается, не предлагая ничего своего. Вся инициатива по поводу условий договора исходит всегда исключительно от клиента/заказчика. И в таком случает, если в каком-то из договоров что-то пошло не так в сторону клиента, разве можно в таком случае рассматривать условно-мошеннические действия со стороны банка? Даже если банк видел изначально, что условия не в пользу клиента/заказчика, но эти условия сам клиент/заказчик по своей инициативе предложил, сам их придумал, сам пришёл, сам предложил и настаивал может даже возможно.
Я, к примеру, вообще не разбираюсь в строительстве и ремонте. У меня на даче дом кирпичный. У него трескается стена. Я изучил довольно много материала по этому поводу, и пришёл к выводу, что это происходит из-за того, что не совсем правильно был сделан фундамент при его строительстве до того, как мы купили дачу. Я сам трачу несколько недель, чтобы изуить этот вопрос досконально, погрузиться в строительную тематику, понять, какие наиболее эффективные решения существуют для этой задачи, 50 раз проконсультируюсь с тем, кто уже столкунлся с этим. И только потом выберу способ, которым буду решать этот вопрос, найму людей, которым дам чёткие инструкции, что конкретно мне нужно сделать (возможно, даже сам приобрету материалы для ремонта). И если после ремонта через какой-то период у меня дом на даче развалится, я никого ни в чём винить не буду. Я сам всё изучил и принял решение. И того же самого ожидаю от всех остальных!
Почему мелкий щрифт обязательно обмануть? Можно мелким шрифтом указать, что велосипед не переделывается в мопед, нн оснащается коляской, крышей, не трансформируется в ракету. И иногда это выход, когда контрагент не хочет в основной части договора ввести понятие велосипед - двухколесное транспортное средство, движимое мускульной силой человека, прилагаемой ногами на педали, сидение анатомической формы, управляется ручным рулем. Тормоза такие-то.
У заказчика есть деньги, он хочет, и даже стремится приобрести опыт, не редко печальный получается. Так бывает и на бытовом уровне, в жизни.
Я проектировал и на старте, и на этапе, когда архитектура была заложена ранее. Но, почти всегда работаю "по гибкому". Есть и успешные велосипеды-ракеты, как то летают криво-косо, что то пробуют (в смысле идеи), идёт - продолжают, не идёт - бросают. Не знать, чего хотеть - это нормально. А сам я разработчик, не маркетолог, не специалист по бизнесу. Кто его знает, как пойдёт бизнес, нужна будет завтра ракета, а мы велик сделали, или сделали ракету, которая нафиг не нужна. Ну и естественно - резиновое тз = резиновый бюджет.
С другой стороны, я строю дом, и, как инжинер - хорошо, что додумался заказать проект, и пропогандирую это среди друзей. Но есть много людей, у кого нет возможности вкладываться в проекты, предварительные оценки, но есть желание сыграть в судьбу - их право.
В общем, как всегда, оба подхода имею право на жизнь, раз они есть.
а как же эгаил?
а что с ним?
@@t0digital а то, что твой подход работает когда ты тратишь чужие деньги, заказчика. и риски постройки ракеты перекладываешь на него, и страхуешь свою ответственность.
можно нанять аналитиков, техписателей, разрабов, тестеров, дивопскоманду, и рабтать работать работать, пока платить будут.
сначала пишешь тз полгода , потом его согласовываешь, потом пишешь этапы, их согласовываешь, потом вносишь изменения в тз, опять согласовываешь, и все строишь и строишь свою ракету. желательно еще договор так составить чтобы заказчик не мог отказаться от твоих услуг без штрафов.
результата все нет, когда спрашивают про результат - тыкаешь его в тз, которое или слишком общее чтобы его реализовать, наинаешь его уточнять - оно начинает противоречить разным своим частям, потому что результат- это всегда компромис, и это дает тебе возможность еще увеличивать стоимость проекта , не давая никакого результата.
а если все таки заказчик дожмет, и пригрозит судом - можешь выкатывать ему устаревшую на годы реализацию, неопробованную, без фитбека. и ни дай бог он попросит что-то добавить или переделать. ты конечно скажешь - нет нет нет "НЕ ПО ТЗ" , тут проще все переделать с нуля))
так что когда мои знакомые хотят потратить все свои деньги на "самолет" - я говорю - закажи сначала велосипед. проверь. попробуй. отбей затраты. полетит - прикрутим мотор
достоинства: есть сразу результат. есть обратная связь.
потому что сам заказчик может не знать, что ему нужно. никто не может этого знать точно, и только в процессе развития проекта он понимает что ему нужно, а что нет.
Канал классный,
И неплохо было бы, чтобы заказчик (по возможности) указал на подобие того, чего он хочет. Например, хочу SAP, но дешевле и понятней. А, тогда вот вам 1С.
Да, аналоги полезны
познавательно)
Это грабли, на которые наступают все начинающие)))
Что-то похожее я смотрел про ремонт в квартире.
Таких заказчиков - чудаков на букву "М" - 70%
Заказчик сам не понимает чего хочет. Но где-то-слышал пару умных слов, а у друзей/конкурентов есть, и мне нужно.
Даже не касаясь программирования. В любом другом направлении - важно ТЗ. И на ТЗ бывает уходит больше времени чем на саму работу/разработку
Я Вам сбрасывал предложения по поводу приложения для мобильных устройств (телефонов). И, увы, не услышал вашего ответа, мнения. Хотел бы, если возможно, понять вашу реакцию на мою идею. Спасибо
Если можно, напишите еще одно письмо, возможно что-то ушло в спам, нужно проверить
@@t0digital написал снова на Вашу почту общую идею проекта. Спасибо
Без ТЗ - результат ХЗ ))
Не совсем согласен,естественно заказчик может не знать разницу между велосипедом,автомобилем,самолетом,но знать чего он хочет исполнитель не то что не обязан ,но и не может.Может же заказчик различать свои желания?))))Он хочет ,чтобы его транспорт ездил ,летал, спал или кофе ему ставил знать то должен.Не нужно заказчику технически объяснять свой заказ,но перед заказом можно немного,совсем чуток исследовать область и его возможности,на основании этого сформировать свои желания и на человеческом языке преподнести свой заказ
Ну, ТЗ на 700 + листов, это нормально ))
-А как же новомодная тенденция на коленке слабать MVP, а затем скрамными спринтами желательно вечно допиливать его валюе до кастомерских реквайрементов и кондишенов-
Хи-хи, поспешил.
Бриф всему голова!
Да и как продать без понимая потребности 🤷🏻
Отеуда такой видок из окна!? Тоже хочу там жить
Ул. Ратная в Москве:)
чувствуется что agile воспринимается как серебряная пуля, но это не так. Уметь им пользоваться, иметь соответсвующий уровень зрелости как команды так и Заказчика - тогда он полезен, и более результативен чем "водопад". Работал много и долго по "водопаду" и Agile, как в больших так и в маленьких командах, И как итог, к "водопаду" возвращаться не хочется.
Еще можно добавить, что быстро, качественно и дешево не бывает )))
«Выбирай любые два»
В целом - видео интересное.. Но с "Agile" вы абсолютно не правы. "Agile" про другое...
Agile - это подход к разработке программного обеспечения, и определяется Agile Manifesto.
Agile не включает практик, а определяет ценности и принципы, которыми руководствуются команды.
Agile Manifesto:
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, всё-таки больше ценится то, что слева...
Чотко! Ну и набор рандомных слов для комента для ютуба...
Интересно, к чему здесь был приведен agile? Методология, очевидно, не подходит для больших проектов. Но в целом, и для больших проектов ее можно использовать, приняв все ее риски (дерьмовая кодовая база и отсутствие спланированной архитектуры либо ее монолитность), которые впоследствии повлекут за собой огромные издержки, примером которых, наверное, является ваш разсказ с мобильным приложением.
Мне кажется, что с хорошим опытом, руководитель команды должен понимать, что за проект перед ними предстал. Оценить самого заказчика, оценить масштабы его бизнеса, проговорить все детали, после чего уже начать разработку, выбрав правильную, по его мнению, методологию.
И agile не говорит о том, что ТЗ нам нафиг не нужно, она говорит о том, что нужно быть всегда готовым к изменениям и стараться писать не монолиты, оставлять возможности для подключения модулей и т.д., ТЗ в ней не отсутствует, оно совсем небольшое, расчитаное только на работоспособность чего-то конкретного, без оценки дальнейших возможных путей развития этого чего-то, что потом и встает боком.
Но все же, повторюсь, для мелких проектов, методология годная и экономит время, ин май опинион, конечно же)
И с чего вдруг парень который нахрен послал недобросовестный?
Есть же ТЗ
@@avazart614 Две сотни раз! Тратить 70% рабочего времени на подтирание соплей заказчику. Супер бизнес схема. Я понимаю что есть откровенные мудаки, но есть и откровенные мозго... ли заказчики.
не согласен с мнением, что в описываемой ситуации вина лежит на заказчике. В данной ситуации оба хороши - если заказываешь нечто уникальное, то должен чётко понимать что ты хочешь получить в итоге.
Да заказчика никто и не винит
@@t0digital Описка. Хотел написать на исполнителе.
Agile может быть полезен крупным компаниям, которые могут себе позволить содержать толпу саморазвивающихся сотрудников
Саморазвивающихся людей крайне мало, тем более, чтобы наполнить ими крупную компанию на сколько-то значимый % от общего количества сотрудников:)
красаве́ц!
красавчик.......
Если вы формошлепская студия -- вам не нужен эджаил, если вы продуктовая компания, которая находится в активной стадии дискавери, то удачи вам с четким планом )
В видео речь о заказчике и исполнителе, что подразумевает заказную разработку. И нет, заказная разработка это не обязательно формошлепство, равно как и продуктовая нередко бывает классическим формошлепством
Диджитализируй! Меня скорее возмутил тон повествования о людях которые видят смысл в эджайл, поэтому я быканул и употребил термин формошлепство, в общем, зря.
Заказчик видимо был Илоном Маском.
Не заказчик чудак, а исполнитель не ценит свое время.
Чудак на букву М 😄
Привет, спасибо .... очень важная тема, жаль только что довольно мало её так видят. Даже если уже пролетали и строили ракету по цене велосипеда не учатся на своих ошибках. Я работаю в большой компании в Германии и сталкиваюсь с этой проблемой каждый день. В своём блоке тоже уже писал статью на эту тему ... заходите буду рад пообщаться www.iot-architect.de/requirements-engineering-superpower-of-a-system-architect
То что нужно ТЗ это все понимают. Но к сожалению нередки случаи когда заказчик этим ТЗ потом подотрется.
Опыт учит выявлять таких заказчиков на этапе написания ТЗ и отказываться от дальнейшей работы с ними. По этапу разработки ТЗ и заказчик может узнать исполнителя, и исполнитель - заказчика.
То судьба IT-обслуги лизать жопу заказчику. Никто не будет создавать такое подробное ТЗ, заказчику не выгодно это.
Есть такое понятие как социальная адаптированость и наличие 2ой сигнальной системы, которую господь бог дал вам в процессе эволюции вида хомо сапиенс )))) или просто сознайтесь в том что Вам лень разговаривать с заказчиком ))))
@@Cooper_Bond причем тут я вообще?
Agile - это как игры без DLC. Хочешь продолжения - плати.
Для всего свои инструменты.
Все круто, но зачем ты постоянно смотришь и поворачиваешь голову в др. сторону. Чуууутка напряжно. Делай дальше, очень круто
Жду анекдотов про Наташу Ростову и поручика Ржевского
Напрасно)
Ты чего 7 красных линий пересказываешь?))
Тссс:)
это как заповеди которые никто не соблюдает, почти никто...
Потому что нужно продать, а не сдать...много фирм не понимают, что сдавать тоже нужно, а многие умеют так уходить от судов, что им и не нужно париться...главное - получить предоплату
Не скажу куда гляжу, принесу то не знаю что . . . История о том, как встретились 2 фантазера и у обоих нет нет понимания что ОНИ хотят получить на выходе к первому (так скажем) числу ! Есть старая пословица или поговорка о том, что все надо решать на берегу . Ибо НеХ...й
красава :)
А как же: "Да я у нормальных спецов всегда заказывал, они почему-то догадывались, что нужно именно так, наверное, потому что нормальные"
Ох, давно такого не встречал:) но это прям да, классика
Есть еще просто идиоты, которые хотят сами не знают чего. Был у меня случай. заказали калькулятор на сайт, сделал, вроде понравилось. Через какое-то время обратились за консультацией по сайту (их фирма мурыжила больше года и никак не заканчивала работу) Я рассказал. в итоге они меня просят сделать. Я им план накидал и все прочее. В итоге они хотели чтобы я за деньги котоыре уже заплачены другим сделал им новый сайт с нуля. В общем отправился такой заказчик в пеший тур по известному адресу.
Все просто - пишем велосипед, облепляем его тестами с головы до ног, а лучше тесты а потом велосипед. Потом пишем тест, чтоб велик перелетел через реку. Нифига он не прошёл, мастырим реактивную тягу к велику, тестируем - зашибись! Ну это в идеале )
А так, бывал я на проекте с ТЗ, которое окаменело с момента создания. Проект вообще ушёл хрен знает куда, тесты стали заваливаться, времени на их починку нехватало, новые тесты тоже не писались, ну или абы как писались, и проект потихонечку стал попахивать тухлятиной. Потом стали-таки ПМ-ы лепить какие-то ТЗ абсолютно не понимая как проект работает, но это все равно что ставить ТЗ на увеличение максимальной скорости автомобиля, тогда как двиган у него троит, коробка скоро уйдёт на тот свет, а колеса проколоты, а времени это все починить хер кто выделит, клиентам нужны фичи )))
После ракеты было бы: а что ваше транспортное средство быстрее скорости света не летает? И пространство искревлять не умеет.... опять урезанно!
Вполне возможно:)
Про аджайл +++++