Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Подтверждаю, на практике оно именно так все и происходит :(.
Ну почему же именно так, иногда и веселее бывает :)
Еще «радует», когда вы с аналитиком увидели систему целиком и формально и точно ее описали — а разработчики… отчаянно тупят и вы, сопротивляясь врожденному гуманизму, вынуждены толкать «мозги нации» в з… цу, прошу прощения
Самое смешное в этой ситуации что если спросить у разработчиков — все получится наоборот =)
Написано от души!
По большому счёту, глоссарий + ER + прототип покрывает бОльшую часть того, что пишется в тысячестраничном ТЗ. Разумеется, если в прототипе у каждого контрола подписано, какому полю какой сущности из ER-ки он соответствует и словами описаны принципы выборок и поведения кнопок. Совокупность ER и протототипов намного более защищена от разночтений, чем объёмистое ТЗ. Собственно, ругать разработчиков за то, что они невнимательно прочитали ТЗ — дело правое, но неблагодарное, поэтому лучше рисовать.
Еще иногда нужно описать алгоритмы, например расчета скидок. Можно в виде Activity диаграммы, можно через State диграмму, можно в ТЗ словами конечно.
Иногда разработчики модели не досматривают до конца :-) Кардиналити реализуют не так, как нарисовано. А еще страшнее, шепотом — когда дело доходит до ссылочной целостности на уровне приложения — у меня один раз спросили перед сдачей проекта несколько лет назад в другой компании, а что это?
Иногда разработчики модели не досматривают до конца :-) Кардиналити реализуют не так, как нарисовано. А еще страшнее, шепотом — когда дело доходит до ссылочной целостности на уровне приложения — у меня один раз спросили перед сдачей проекта несколько лет назад в другой компании, а что это?
А я еще добавлю. Если вы программист/разработчик в такой команде (где на 3 программистов 2 бездельника: техн. директор и менеджер/аналитик) — валите пока не поздно. От работы по перепиливанию магентовского/друпаловского/джумловского/вордпрессового/битриксовского кривокода ничего хорошего не выйдет, не будет ни роста профессионального уровня, ни хорошего настроения. Вы либо станете мартышкой за клавиатурой, либо впадете в депрессию (хоть я и не верю, что она вообще существет в природе, но все же).
Ну и насчет Zend Framework в высоконагруженных проектах — sounds weird, ни вконтакт, ни фейсбук не используют, да и я бы не стал использовать, так как он слишком универласелен, вы будете использвоать 5% возможностей, а вот тормозить все это будет на все 100. Общая идея и концепции в нем хорошие и интересные, но в реальности использовать вместе с тормозным скриптовым языком еще и монстроподобный фреймворк… тут никакой сервер не потянет. Плюс, многие компоненты сделаны ужасно, формы и View например.
Ну и насчет Zend Framework в высоконагруженных проектах — sounds weird, ни вконтакт, ни фейсбук не используют, да и я бы не стал использовать, так как он слишком универласелен, вы будете использвоать 5% возможностей, а вот тормозить все это будет на все 100. Общая идея и концепции в нем хорошие и интересные, но в реальности использовать вместе с тормозным скриптовым языком еще и монстроподобный фреймворк… тут никакой сервер не потянет. Плюс, многие компоненты сделаны ужасно, формы и View например.
Если программист сможет разобраться в коробочном продукте — он приобрает хороший системный опыт выживания в море кода. Не все это могут, некоторые ломаются и остаются на уровне пары тройку классиков.
Под юникс пишут же софт — приспосабливаются :-) А что, юникс правильно написан на ООП — нет.
Под j2ee чтобы писать правильно нужно дофига изучить готового кода и прочитать массу книг. Своего рода тоже коробка.
Я лично знаю много отличных разработчиков, владеющих ООП и паттернами проектирования, которые смогли разобраться и научились уважать коробки. Мало того, коробочная разработка приносит ребятам неплохой доход, в отличие от крутого ООП… для души.
Под юникс пишут же софт — приспосабливаются :-) А что, юникс правильно написан на ООП — нет.
Под j2ee чтобы писать правильно нужно дофига изучить готового кода и прочитать массу книг. Своего рода тоже коробка.
Я лично знаю много отличных разработчиков, владеющих ООП и паттернами проектирования, которые смогли разобраться и научились уважать коробки. Мало того, коробочная разработка приносит ребятам неплохой доход, в отличие от крутого ООП… для души.
Про Zend заявление в стиле — не писал, но осуждаю. Про facebook и vkontakte — а еще они патчат ядро ОС, пишут свои веб-сервера и БД, давайте тоже начнем разработку с этого. Не надо сравнивать жопу с пальцем.
Я что то не догнал. За пол года на Rails, да еще силой нескольких человек можно запустить какого-то просто монстра. Не понял в чем подвох про «4 месяца». Ну только если на этапе согласования дизайна с заказчиком будет пипец.
Во вторых — если в начале нет подписанного ТЗ — а как организовать сдачу проекта? Ну понимаете, бюджет обозначен, значит заказчик попытается все что можно трактовать в свою пользу. Если у вас нет ТЗ, то тут то, на этом самом этапе вы и выбьетесь из срока — потому что при виде реальных вещей у клиента обычно просыпается креатив «а еще было бы клево добавить это» — вот тут то да, хорошо если за год закончите. Хорошо если не разосравшись с клиентом по поводу счета за работу.
Во вторых — если в начале нет подписанного ТЗ — а как организовать сдачу проекта? Ну понимаете, бюджет обозначен, значит заказчик попытается все что можно трактовать в свою пользу. Если у вас нет ТЗ, то тут то, на этом самом этапе вы и выбьетесь из срока — потому что при виде реальных вещей у клиента обычно просыпается креатив «а еще было бы клево добавить это» — вот тут то да, хорошо если за год закончите. Хорошо если не разосравшись с клиентом по поводу счета за работу.
Я тут про php писал. ТЗ… хотелось же по хорошему, по человечески, по Agile методологии.
Если коробка то тут можно аккуратно без большого ТЗ. В ТЗ вписываем только то, что нужно в этой коробке доделать/переделать. Если коробка имеет документацию, то на нее ссылки из ТЗ.
Поэтому показываю, что за 4 месяца можно и магазин написать и ТЗ большое не делать :-)
Если коробка то тут можно аккуратно без большого ТЗ. В ТЗ вписываем только то, что нужно в этой коробке доделать/переделать. Если коробка имеет документацию, то на нее ссылки из ТЗ.
Поэтому показываю, что за 4 месяца можно и магазин написать и ТЗ большое не делать :-)
Да, большое «бюрократическое» ТЗ, как правило, не нужно.
Тут цель ТЗ — скорее убедиться что вы правильно поняли заказчика, и описать все на русском языке. Потому что изменять ТЗ на начальном этапе все таки проще, чем переделывать код в конце.
Скорее, это все таки страховка, позволяющая избегать затягивания проекта под конец — заказчик должен понимать свою ответственность за свои хотелки.
Тут цель ТЗ — скорее убедиться что вы правильно поняли заказчика, и описать все на русском языке. Потому что изменять ТЗ на начальном этапе все таки проще, чем переделывать код в конце.
Скорее, это все таки страховка, позволяющая избегать затягивания проекта под конец — заказчик должен понимать свою ответственность за свои хотелки.
Та часть которая от КО (про глоссарий, про аналитиков, про опросы, про квадратики со стрелочками, и даже про преимущества готовых решений) — да всё хорошо и правильно. Но как только начинаются эмоциональные оценки и «юморок из презентаций 'гуру'» — впечатление резко портится.
Вот была компания, работала. В ней был отдел разработки и тоже работал. И всё у них было не то чтобы прям очень хорошо, но в среднем — неплохо. И вот появился в компании новый манагер проектов которому поручили за 4 месяца открыть интернет-магазин. Он взялся за дело и делал в целом всё не плохо. Но вот в какой-то момент, вместо того чтобы решать проблемы и двигаться к результату, он начал «дёргать рубильники», «требовать кадровых перестановок», и всячески показывать что он то «за дело», и всё бы хорошо но вот только разработчики халтурят, бездельничают, проще говоря «Козлы». Естественно — начальнику разработки «козлом» быть не хочется. И тут начинаются чудеса — в ТЗ находится много ошибок и каждая ошибка постфактум начинает раздуваться как оч серьёзная, из-за которой все сроки и сорваны. Да и начальники других отделов — не бездельничают (как могло показаться из картинок манагера и аналитика), а работают в поте лица. И вот вся эта братия совместными усилиями проект разваливает + ведёт информационные войны с понятной целью.
В итоге — магазин не запущен, манагер уволился. Печаль.
Вот была компания, работала. В ней был отдел разработки и тоже работал. И всё у них было не то чтобы прям очень хорошо, но в среднем — неплохо. И вот появился в компании новый манагер проектов которому поручили за 4 месяца открыть интернет-магазин. Он взялся за дело и делал в целом всё не плохо. Но вот в какой-то момент, вместо того чтобы решать проблемы и двигаться к результату, он начал «дёргать рубильники», «требовать кадровых перестановок», и всячески показывать что он то «за дело», и всё бы хорошо но вот только разработчики халтурят, бездельничают, проще говоря «Козлы». Естественно — начальнику разработки «козлом» быть не хочется. И тут начинаются чудеса — в ТЗ находится много ошибок и каждая ошибка постфактум начинает раздуваться как оч серьёзная, из-за которой все сроки и сорваны. Да и начальники других отделов — не бездельничают (как могло показаться из картинок манагера и аналитика), а работают в поте лица. И вот вся эта братия совместными усилиями проект разваливает + ведёт информационные войны с понятной целью.
В итоге — магазин не запущен, манагер уволился. Печаль.
Я понимаю вас. Создается техническая мафия, которая вяло, ковыряясь пальцем в носу, поделывает пописывает проекты. Конечно, когда приходит управленец, который снизу подсвечивает безответственность и разгильдяйство — его не любят, особенно если получают неплохие деньги за процесс, который и так идет. :-)
Тут ведь всё относительно и у каждого участника тех событий окажется своя правда и тысячи аргументов в поддержку своей версии.
Просто из поста складывалось ощущение что «крутой нрав» — одно из слагаемых успеха. Я хотел показать что это вполне может быть не так. Один в поле не воин и в ситуации, когда «манагер» попытается выставит всех идиотами и бездельниками — поставленной цели он может и не добиться. Особенно когда на стороне «идиотов» месяцы/годы совместной б.м. нормальной работы.
Более гибким надо быть. Стремление «в лоб» убедить людей в том, что они ничего не делают или публично это показать — позитивных результатов не принесёт, а отношения испортит и сделает достижение цели ещё более сложным. Ведь мало кто готов помогать в решении проблем человеку, который вчера перед «генеральным» пытался выставить весь отдел идиотами.
Просто из поста складывалось ощущение что «крутой нрав» — одно из слагаемых успеха. Я хотел показать что это вполне может быть не так. Один в поле не воин и в ситуации, когда «манагер» попытается выставит всех идиотами и бездельниками — поставленной цели он может и не добиться. Особенно когда на стороне «идиотов» месяцы/годы совместной б.м. нормальной работы.
Более гибким надо быть. Стремление «в лоб» убедить людей в том, что они ничего не делают или публично это показать — позитивных результатов не принесёт, а отношения испортит и сделает достижение цели ещё более сложным. Ведь мало кто готов помогать в решении проблем человеку, который вчера перед «генеральным» пытался выставить весь отдел идиотами.
Согласен. Не верю, что без системного подхода можно браться за сколь серьезные проекты. В статье старался описать выстраивание системы управления — открытой и честной. Ну сделали мне спринт фекалийного качества — давайте собираться и смотреть в чем дело, разбирать полеты.
Но есть момент. Иногда попадаются группы людей одного уровня — средне-низкого, спаянные тусением и взаимным раздолбайством. И им бесполезно что-либо доказывать, показывать, объяснять — в этом случае нужно решать проблему на уровне выше.
Да, до боли знакомые процессы. Вообще agile методологии хорошо подходят в плане гибкости сроков, оплаты и взаимоотношения с клиентом. Потому что наперед выдается продукт и заказчик быстрее видит результат, проще вносить какие-то изменения. Раньше я больше к RUP склонялся, импонировала изначальная четкость задач, но со временем такой подход стал костью в горле )
Есть ещё маленький фокус, за который вас правда будут ненавидеть, но сроки ускорите если уж совсем жмет: конкурентная разработка — каждая задача решается двумя допустим людьми, или двумя командами если очень большая, после сдачи обе команды тестируют до чертиков работу противника ) По совокупности затраченного времени и количества выявленных багов начисляются баллы. В конце проекта по этим баллам назначаются хороооошие премии ) Ну и к тому же рейтинг программистов позволяет давать лучшим более интересные задачи, а остальных заставляет стараться свой рейтинг поднять. Оживленность и заинтересованность в команде резко прибавится, ненавидеть вас будут жестко, но ведь задача руководителя и не стоит в том чтобы быть хорошим дружбаном для разработчиков.
Правда такой подход достаточно экстремальный ) Он не для каждой команды подходит. Я лично использовал его для работы с удаленными сотрудниками, там и текучка больше. Те кто опускался в рейтинге вниз больше на проекты не приглашался.
Есть ещё маленький фокус, за который вас правда будут ненавидеть, но сроки ускорите если уж совсем жмет: конкурентная разработка — каждая задача решается двумя допустим людьми, или двумя командами если очень большая, после сдачи обе команды тестируют до чертиков работу противника ) По совокупности затраченного времени и количества выявленных багов начисляются баллы. В конце проекта по этим баллам назначаются хороооошие премии ) Ну и к тому же рейтинг программистов позволяет давать лучшим более интересные задачи, а остальных заставляет стараться свой рейтинг поднять. Оживленность и заинтересованность в команде резко прибавится, ненавидеть вас будут жестко, но ведь задача руководителя и не стоит в том чтобы быть хорошим дружбаном для разработчиков.
Правда такой подход достаточно экстремальный ) Он не для каждой команды подходит. Я лично использовал его для работы с удаленными сотрудниками, там и текучка больше. Те кто опускался в рейтинге вниз больше на проекты не приглашался.
Зато какой накал страстей! Спасибо за совет, плюсую.
Экстримально да и Джоэл Спольски, наверное бы, поспорил с данным методом, но для удаленной работы вполне может работать хорошо. Вот его цитата:
Предположим, вы решили награждать разработчика с наименьшим количеством багов. Теперь каждый раз, когда тестировщик пытается сообщить об ошибке, это превращается в большой спор, и, как правило, разработчик убеждает тестировщика в том, что на самом деле это не баг. Или тестировщик соглашается сообщать разработчику о багах «неофициально», перед тем как вносить их в багтреккинговую систему. И никто больше не пользуется багтреккинговой системой. Число ошибок снижается, но на самом деле их остается столько же.
Разработчики очень сообразительны в этом отношении. Что бы вы ни пытались измерить, они найдут способ оптимизировать этот показатель, и вы никогда не получите именно то, чего пытаетесь добиться.
Предположим, вы решили награждать разработчика с наименьшим количеством багов. Теперь каждый раз, когда тестировщик пытается сообщить об ошибке, это превращается в большой спор, и, как правило, разработчик убеждает тестировщика в том, что на самом деле это не баг. Или тестировщик соглашается сообщать разработчику о багах «неофициально», перед тем как вносить их в багтреккинговую систему. И никто больше не пользуется багтреккинговой системой. Число ошибок снижается, но на самом деле их остается столько же.
Разработчики очень сообразительны в этом отношении. Что бы вы ни пытались измерить, они найдут способ оптимизировать этот показатель, и вы никогда не получите именно то, чего пытаетесь добиться.
Ну я не пробовал, конечно, но думаю и в офисной работе это можно решить чисто организационными и техническими методами. Устранив допустим взаимодействие между тестерами и программистами, снизив до минимума взаимодействие между сотрудниками вообще как это бывает при удаленной работе. Каждый должен быть сам за себя, коллективизм тут во вред.
Хотя может для классической офисной работы такой вариант и не покатит, было бы интересно услышать мнения опытных офисных менеджеров и руководителей на этот счет, а ещё лучше произвести эксперимент )
Хотя может для классической офисной работы такой вариант и не покатит, было бы интересно услышать мнения опытных офисных менеджеров и руководителей на этот счет, а ещё лучше произвести эксперимент )
Простите, но вы описываете процесс так, будто задача должна быть реализована за 1 месяц, а не зна 4.
Я откровенно не понимаю, что можно писать 4 месяца в 4 пары рук на фреймворке. Точно, что фейсбук можно написать, вместе с апи и соц графом. Я привык к другим темпам разработки…
Ну а так, в целом, где-то так и есть. Кстати, обычно, даже при наличии ТЗ, все равно процесс сваливается в agile. Это, наверное, скверно, но почему-то так почти всегда…
Я откровенно не понимаю, что можно писать 4 месяца в 4 пары рук на фреймворке. Точно, что фейсбук можно написать, вместе с апи и соц графом. Я привык к другим темпам разработки…
Ну а так, в целом, где-то так и есть. Кстати, обычно, даже при наличии ТЗ, все равно процесс сваливается в agile. Это, наверное, скверно, но почему-то так почти всегда…
Ну да, по всем оценкам на покере релиз на коробке должен завершиться за 4 спринта — но, черт, появляются спринты под названием «Стабилизация», «Углубленное тестирование», «Исправление багов», «Тестирование после исправления багов», «Разгон системы, зависшей после исправления багов» — я совершенно серьезно. И поэтому тут и 4 и 6 месяцев и… год может пройти :-)
а мне показалось, что статья была написана ради одной фразы)
все и так знают, что фейсбук написан на ZendFramework, ООП сочинили разработчики для прокачивания зряплаты, а юнит-тестирование — чтобы затягивать разработку на год. но вообще, после такого заявления, я надеялся, что будет презентация десятка интернет-магазинов, которые после 3-4 месяцев разработки по предложенной схеме, уже 2-3 года успешно работают без привлечения разработчиков, управляемые через админку счастливым PO… или хотя бы пару… ведь где-то они существуют?)
остальное и так очевидно. Agile придумали разработчики для того, чтобы PO можно было не составлять ТЗ. чудесный Scrum даётся им в награду за лояльность и прилежность (иначе будет RUP). не поянтно, зачем тратить месяц аналитики на составление глоссария, E-R модели, прототипов интерфейсов, когда в итоге PO ратует за коробку вне всяких конкуретнов, которая все равно навяжет собственное решение, включая терминологию, архитектуру и интерфейсы?
понятно — аналитик лучший друг PO и ему через месяц нужно на что-то ехать в отпуск. вероятно он уже избит настолько, что не в силах решать _задачи_ на том уровне, где они возникают. но неужели лучший друг запарился настолько, что путается в собственных терминах? я не знаю, что ему рассказывали ваши дети после уроков логики, но E-R всю жизнь была концептуальной моделью, а не логической. логика это формальная система, а не просто набор популярных мемов -)
хотите после запуска проект САМОСТОЯТЕЛЬНО через админку управлять сайтом, не привлекая программистов для малейшего изменения функционала — тут разумеется коробка от 1С-Битрикс вне всяких конкурентов. Вы запуститесь в срок и ближайшие 2-3 года будете плевать в поток — управляя сайтом через админку без привлечения разработчиков.может быть поэтому весь остальной антураж из модных словечек выглядит притянутым за уши?..
все и так знают, что фейсбук написан на ZendFramework, ООП сочинили разработчики для прокачивания зряплаты, а юнит-тестирование — чтобы затягивать разработку на год. но вообще, после такого заявления, я надеялся, что будет презентация десятка интернет-магазинов, которые после 3-4 месяцев разработки по предложенной схеме, уже 2-3 года успешно работают без привлечения разработчиков, управляемые через админку счастливым PO… или хотя бы пару… ведь где-то они существуют?)
остальное и так очевидно. Agile придумали разработчики для того, чтобы PO можно было не составлять ТЗ. чудесный Scrum даётся им в награду за лояльность и прилежность (иначе будет RUP). не поянтно, зачем тратить месяц аналитики на составление глоссария, E-R модели, прототипов интерфейсов, когда в итоге PO ратует за коробку вне всяких конкуретнов, которая все равно навяжет собственное решение, включая терминологию, архитектуру и интерфейсы?
понятно — аналитик лучший друг PO и ему через месяц нужно на что-то ехать в отпуск. вероятно он уже избит настолько, что не в силах решать _задачи_ на том уровне, где они возникают. но неужели лучший друг запарился настолько, что путается в собственных терминах? я не знаю, что ему рассказывали ваши дети после уроков логики, но E-R всю жизнь была концептуальной моделью, а не логической. логика это формальная система, а не просто набор популярных мемов -)
Я не писал про E-R модель :-), если читали внимательно.
Одна из целей статьи — объективно показать PO когда коробочное решение действительно может принести ему выгоду. А когда не может.
Список успешных решений на коробках можете посмотреть в моем портфолио — я не хочу грузить маркетинговым булшитом уважаемых коллег :-)
Мемы и другие техники манипулирования сознанием — не приветствую. Предпочитаю делиться личным опытом и наблюдениями.
Одна из целей статьи — объективно показать PO когда коробочное решение действительно может принести ему выгоду. А когда не может.
Список успешных решений на коробках можете посмотреть в моем портфолио — я не хочу грузить маркетинговым булшитом уважаемых коллег :-)
Мемы и другие техники манипулирования сознанием — не приветствую. Предпочитаю делиться личным опытом и наблюдениями.
>> а мне показалось, что статья была написана ради одной фразы)
Человек там работает все-таки. Не мог не упомянуть :)
Человек там работает все-таки. Не мог не упомянуть :)
Очень хорошая статья, спасибо автору.
Важным является примечание на тему того, что, если вы не нашли поддержки у топов в процессе выявления требований, то стоит увольняться.
Потому что успеха проекта не предвидится. Но, кстати, может оказаться так, что зп вы будете получать и после неуспеха проекта )
Важным является примечание на тему того, что, если вы не нашли поддержки у топов в процессе выявления требований, то стоит увольняться.
Потому что успеха проекта не предвидится. Но, кстати, может оказаться так, что зп вы будете получать и после неуспеха проекта )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Счастливый ProductOwner — верхом на пороховой бочке