Привет! Раньше в it конторах хоть как то в респектах были разработчики.
Счас какая-то хрень, набрали на одного разраба по 2 qa и по 2 мэнэджера, они сидят в носу ковыряют, важные такие, один
есть у нас Lead QA, жирный такой, ленивый, важный. А сам тупой, как валенок. Даже авто тесты не может написать. Вот накуя они нужны? ведь разрабы без них обойдуться, а они без них нет.
Только бюджет компании проедают. Что за тенденция? И лезут же, лезут, знаний нет, а пирог IT вкусный, за счет наглости кусочек урвать то хотят. С одного митинга на другой ходят. Создают видимость работы. ДА нахрен ваши митинги, продукты пишут разрабы, а вы там хоть обмитингуйтесь, ни хрена само не напишеться.
первый — для того, чтобы составить план тестирования глядя на список требований к программе,
второй — для того, чтобы составить список требований к программе.
Разработчик же не будет заниматься такой фигнёй как какие-то там документы? Ну вот те двое и компенсируют дикость программера, выводя изделие в целом с пещерного уровня на уровень современной цивилизации, имеющей письменность.
Здравствуйте, cocacola, Вы писали:
C>Счас какая-то хрень, набрали на одного разраба по 2 qa и по 2 мэнэджера, они сидят в носу ковыряют, важные такие.
От одного менеджера ты фиг избавишься, но тестеры и аналитики, на мой взгляд, это лишний груз.
Здравствуйте, StanislavK, Вы писали:
SK>От одного менеджера ты фиг избавишься, но тестеры и аналитики, на мой взгляд, это лишний груз.
Ох не попадалось вам работать с толковыми менеджерами, тестерами и аналитиками.
Оченно от них ото всех большая польза.
Ибо решают они свой круг задач, снимая этот головняк с тебя.
Если же только бестолковые попадаются то да, понять зачем оно надо сложновато.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, StanislavK, Вы писали:
SK>>От одного менеджера ты фиг избавишься, но тестеры и аналитики, на мой взгляд, это лишний груз. CC>Ох не попадалось вам работать с толковыми менеджерами, тестерами и аналитиками.
Не поверишь, как не поговорю с ними, так и говорят! Ты, говорят, просто не понимаешь как мы нужны! Плати давай нам бабло!
CC>Оченно от них ото всех большая польза. CC>Ибо решают они свой круг задач, снимая этот головняк с тебя.
Наброшу конечно говна, но все же.
Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически. Да, не все приложения написаны так, что это возможно, но это их проблемы и так им и надо.
Когда же встает задача тестирования работы приложения при реальной коммуникации с другими системами, то там тоже нефиг тестеров брать — разрабы быстро выбешиваются от этого и пилят всякие приблуды, чтобы этого руками не делать.
Теперь аналитики. Тут я совсем теряюсь. Они типа должны говорить с бизнесом узнавать, что же они хотят, потом это аккуратно записывать и передавать дальше. Ессесно это порождает кучу процесса, вопросов и документации, что в итоге все замедляет и искажает изначальные требования. Еще это поощряет тупых разработчиков с подходом типа "А че, я накодил как написано было!".
Что же мешает разработчику самому поговорить с бизнесом и все закодить я понять не могу. Решит много проблем — надо меньше документыции, меньше процесса, из-за экономии времени фичи тоже становятся меньше, так как бизнес не старается впихнуть все и сразу из-за боязни, что шас все убегут делать и пол-года ни фич и ни фидбэка.
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, CreatorCray, Вы писали:
CC>>Здравствуйте, StanislavK, Вы писали:
SK>>>От одного менеджера ты фиг избавишься, но тестеры и аналитики, на мой взгляд, это лишний груз. CC>>Ох не попадалось вам работать с толковыми менеджерами, тестерами и аналитиками. SK>Не поверишь, как не поговорю с ними, так и говорят! Ты, говорят, просто не понимаешь как мы нужны! Плати давай нам бабло!
дело не в том, что говрят они. Делов в том, что есть разрабы, работавшие с клевыми тестерами, аналитиками, и , не побоюсь этого слова — менеджерами.
И по опыту этих людей такие роли на проекте были полезны.
Что, конечно, не отменяет вашего опыта работы с бестолковыми аналитиками. Но бестолковые спецы есть в любой области, в разработке их не меньше, а вреда от них — больше
SK>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически.
Это как, юнит тестами? Это необходимо, но не достаточно.
Если же вы пишете автоматизированные тесты, если проводите нагрузочное тестирование и т.д. — то значит, вы выполняете работу тестеров вместо них
SK>Теперь аналитики. Тут я совсем теряюсь. Они типа должны говорить с бизнесом узнавать, что же они хотят, потом это аккуратно записывать и передавать дальше. Ессесно это порождает кучу процесса, вопросов и документации, что в итоге все замедляет и искажает изначальные требования. Еще это поощряет тупых разработчиков с подходом типа "А че, я накодил как написано было!".
Это, как было сказано выше, потому что неправильные аналитики вам попадались. Аналитик должен не быть передастом, переклаывая кучку говнотребований из однго места в другое. А Должен выдавать полные и непротиворечивые требования, понятные разработчику, технически реализуемые. Должен быть спецом предметной области заказчика. Должен структурировать поток бреда, генерируемый заказчиком. Согласовывать бред нескольких представителей заказчика друг с другом.
У меня был опыт, когда этим всем занимались разрабы, а потом появились аналитики. Сразу такой груз снялся с плеч! И, главное, было сохранены нервы разрабов и освободилось время что-то реально разрабатывать, а не совещания совещать
SK>Что же мешает разработчику самому поговорить с бизнесом и все закодить я понять не могу.
Если разработчик начитает формировать требования в процессе общения с бизнесом — он сам становится аналитиком
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, StanislavK, Вы писали:
SK>>От одного менеджера ты фиг избавишься, но тестеры и аналитики, на мой взгляд, это лишний груз.
CC>Ох не попадалось вам работать с толковыми менеджерами, тестерами и аналитиками. CC>Оченно от них ото всех большая польза. CC>Ибо решают они свой круг задач, снимая этот головняк с тебя. CC>Если же только бестолковые попадаются то да, понять зачем оно надо сложновато.
Есть оборотная сторона. Разработчики хуже вникают в то что именно они делают. Они по любому будут разбираться в продукте хуже, чем тестеры. В итоге происходит рассинхрон между реализацией и тем что нужно. Например, если софт работает медленно тестеры и не подозревают что можно было бы быстрее, а разрабы не подозревают что нужно быстрее. Они же не особо с продуктом работают.
То же самое с аналитикой, нужно чтобы разработчики говорили с ЗЛ (заинтересованное лицо). Ибо зная изнутри систему можно подкинуть идеи, либо реализовать совсем иначе, что устроит ЗЛ.
Здравствуйте, Gradiens, Вы писали:
G>Что, конечно, не отменяет вашего опыта работы с бестолковыми аналитиками. Но бестолковые спецы есть в любой области, в разработке их не меньше, а вреда от них — больше
А кто сказал, что они были бестолковые? Все умнейшие люди и знают свое дело. Но дело не в этом. И с хорошими аналитиками да, не хуже, в большистве случаев. Глобальная проблема в том, что очень сложно контролировать то, что как-бы работает — аналитики анализируют, тестеры тестируют, программисты программируют, все вроде заняты. А вот тут фигак, нет больше тестеров и оказывается что, вау, хз, чем они большей частью занимались — продукт можно делать с там же качаеством просто написав чуть больше тестов, чуть больше думая головой и гоняя автоматические инграционные тесты. С аналитиками та же фигня.
SK>>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически. G>Это как, юнит тестами? Это необходимо, но не достаточно. G>Если же вы пишете автоматизированные тесты, если проводите нагрузочное тестирование и т.д. — то значит, вы выполняете работу тестеров вместо них
Да, именно так и значит. И очень стараемся сделать так, чтобы ее было меньше и больне никогда к ней не возвращаться. Признаться, я не вижу разницы в написании одного типа кода или другого, зачем для этого разные люди?
SK>>Теперь аналитики. Тут я совсем теряюсь. Они типа должны говорить с бизнесом узнавать, что же они хотят, потом это аккуратно записывать и передавать дальше. Ессесно это порождает кучу процесса, вопросов и документации, что в итоге все замедляет и искажает изначальные требования. Еще это поощряет тупых разработчиков с подходом типа "А че, я накодил как написано было!". G>Это, как было сказано выше, потому что неправильные аналитики вам попадались. Аналитик должен не быть передастом, переклаывая кучку говнотребований из однго места в другое. А Должен выдавать полные и непротиворечивые требования, понятные разработчику, технически реализуемые. Должен быть спецом предметной области заказчика. Должен структурировать поток бреда, генерируемый заказчиком. Согласовывать бред нескольких представителей заказчика друг с другом.
Как так он не "передаст", если он "должен выдавать полные и непротиворечивые требования, понятные разработчику" из требований бизнеса? Еще какой "передаст", только этим и занимается. Если заказчик бредовый, то да, надо как-то решать проблему, но это тогда специально человек "для общения со сложным заказчиком" и он не нанимается просто по умолчанию.
G>У меня был опыт, когда этим всем занимались разрабы, а потом появились аналитики. Сразу такой груз снялся с плеч! И, главное, было сохранены нервы разрабов и освободилось время что-то реально разрабатывать, а не совещания совещать
А нефиг было совещания совещать. Не, серьезно. Если процесс поставлен так, что совещая надо совещать, то да, тут без совещателей не обойтись.
SK>>Что же мешает разработчику самому поговорить с бизнесом и все закодить я понять не могу. G>Если разработчик начитает формировать требования в процессе общения с бизнесом — он сам становится аналитиком
Да, становится. И бизнес знает и сам влияет на продукт.
А я как тестировщик согласен что мы нафиг не нужны для части проектов)
Мы сейчас на новом витке развития процессов разработки и модель "пм-аналитик-архитектор-разработчик-тестировщик-техпис-внедрятель-поддержка" должна для части проектов (где важно качество продукта) быть изменена на старую модель "разработчик-разработчик".
Тогда ответсвенность повысится и продукт будет лучше. Пусть и чуть меньшей моментальной скорости разработки. Как мне видится просто нужно больше чего-то типа ТДД (БДД) и парного программирования (и других практик). И даже может в цене разработка не вырастет, а оплата может подняться серьезно.
А то уже дожили что все пишут код (и налитики, и тестировщики, и админы-девопсы), но все пишут плохо (включая разработчиков в среднем). Даешь старую добрую качественную разработку на новых технологиях и с новыми подходами!
Здравствуйте, cocacola, Вы писали:
C>Привет! Раньше в it конторах хоть как то в респектах были разработчики. C>Счас какая-то хрень, набрали на одного разраба по 2 qa и по 2 мэнэджера, они сидят в носу ковыряют, важные такие, один C>есть у нас Lead QA, жирный такой, ленивый, важный. А сам тупой, как валенок. Даже авто тесты не может написать. Вот накуя они нужны? ведь разрабы без них обойдуться, а они без них нет. C>Только бюджет компании проедают. Что за тенденция? И лезут же, лезут, знаний нет, а пирог IT вкусный, за счет наглости кусочек урвать то хотят. С одного митинга на другой ходят. Создают видимость работы. ДА нахрен ваши митинги, продукты пишут разрабы, а вы там хоть обмитингуйтесь, ни хрена само не напишеться.
Мэнэджер должен руководить процессом разработки.
Lead QA должен руководить процессом тестирования.
И в том и том случае полно организационной работы которую девелоперу не понять если нет такого опыта.
Думать что "разрабы без них обойдуться" несколько наивно, как в прочем и судить о их тупизне и бесполезности митингов.
Если в процессе участвует только "разраб" то это называется наколеночное производство CMM уровень 1 (при 5 возможных).
Как исключение "разраб" может делать все (не факт что качественно). Но в таком случае он будет физически не успевать.
Если так думать то можно исключить всех кто не производит основной продукт, например бухгалтерию.
Единственно что верно в сообшении что на одного "разрабы" по 2 qa и по 2 мэнэджера быть не должно.
Здравствуйте, Gradiens, Вы писали:
G>Если разработчик начитает формировать требования в процессе общения с бизнесом — он сам становится аналитиком
И это очень круто и очень сильно ценится. Такие обычно работают контракторами/консультантами за очень серьёзные бабки, которые обычным кодерам не платят, т.к. такой человек-оркестр позволяет убрать отдельного аналитика и съэкономить бабки даже несмотря на то, что платить ему приходится существенно выше обычного.
Здравствуйте, StanislavK, Вы писали:
SK>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически.
Далеко не всё так можно протестировать.
SK>Да, не все приложения написаны так, что это возможно, но это их проблемы и так им и надо.
То, что ты не сталкивался с такими задачами говорит лишь о том, где построена твоя колокольня.
SK>Когда же встает задача тестирования работы приложения при реальной коммуникации с другими системами, то там тоже нефиг тестеров брать — разрабы быстро выбешиваются от этого и пилят всякие приблуды, чтобы этого руками не делать.
А руками нормальные тестеры и не делают, они автоматизацию пишут, сами.
SK>Что же мешает разработчику самому поговорить с бизнесом и все закодить я понять не могу.
1. Человек не может находиться в двух местах одновременно.
2. В сутках 24 часа.
3. Человек устаёт и ему надо отдохнуть.
4. После кучи говорильни с заказчиком на собственно работу времени не остаётся.
SK>надо меньше документыции, меньше процесса, из-за экономии времени фичи тоже становятся меньше, так как бизнес не старается впихнуть все и сразу из-за боязни, что шас все убегут делать и пол-года ни фич и ни фидбэка. Я когда то давно тоже так думал, пока проекты были крошечные.
Здравствуйте, Gattaka, Вы писали:
G>В итоге происходит рассинхрон между реализацией и тем что нужно.
Это задача менеджмента — отслеживать что надо и что сделано.
Здравствуйте, cocacola, Вы писали:
C>Только бюджет компании проедают. Что за тенденция? И лезут же, лезут, знаний нет, а пирог IT вкусный, за счет наглости кусочек урвать то хотят. С одного митинга на другой ходят. Создают видимость работы. ДА нахрен ваши митинги, продукты пишут разрабы, а вы там хоть обмитингуйтесь, ни хрена само не напишеться.
Чувак, ты только что открыл, как разрабатывать продукта в два раза дешевле, чем это делают другие конторы.
Срочно открывай свой бизнес и реализуй это конкурентное преимущество — озолотишься!
Здравствуйте, StanislavK, Вы писали:
SK>Теперь аналитики. Тут я совсем теряюсь. Они типа должны говорить с бизнесом узнавать, что же они хотят, потом это аккуратно записывать и передавать дальше. Ессесно это порождает кучу процесса, вопросов и документации, что в итоге все замедляет и искажает изначальные требования. Еще это поощряет тупых разработчиков с подходом типа "А че, я накодил как написано было!". SK>Что же мешает разработчику самому поговорить с бизнесом и все закодить я понять не могу.
Здравствуйте, cocacola, Вы писали:
C>Привет! Раньше в it конторах хоть как то в респектах были разработчики. C>Счас какая-то хрень, набрали на одного разраба по 2 qa и по 2 мэнэджера, они сидят в носу ковыряют, важные такие, один C>есть у нас Lead QA, жирный такой, ленивый, важный. А сам тупой, как валенок. Даже авто тесты не может написать. Вот накуя они нужны? ведь разрабы без них обойдуться, а они без них нет. C>Только бюджет компании проедают. Что за тенденция? И лезут же, лезут, знаний нет, а пирог IT вкусный, за счет наглости кусочек урвать то хотят. С одного митинга на другой ходят. Создают видимость работы. ДА нахрен ваши митинги, продукты пишут разрабы, а вы там хоть обмитингуйтесь, ни хрена само не напишеться.
У бородатого элемента копроэкономики, занятого веб-дизайном, обе ручки сильно заняты, надо быстро колотить по клавиатуре, производя копродукт.
А этот продукт за ним впоследствии кому-то следует убирать, вот QA и прочие автоматизаторы этим и занимаются. У самого вебдизайнера рефлекторный навык подтирания уже атрофировался.
Здравствуйте, cocacola, Вы писали:
C>Привет! Раньше в it конторах хоть как то в респектах были разработчики.
Менеджер — понятие растяжимое, их в разработке много всяких разных с разными обязанностями. Но правильный менеджер это такой, который делает так, чтобы разработчики занимались тем, чем они заниматься любят и умеют, не отвлекаясь на всякую фигню. Но чтобы процесс разработки оставался при этом относительно прогнозируемым и управляемым.
Здравствуйте, playnext, Вы писали:
P>Мэнэджер должен руководить процессом разработки.
Не руководить, а организовывать. Это не совсем одно и тоже. Но да, в некоторых конторах, особенно бСССР, PM это другое название для начальника отдела. При таком построении есть суровый риск, что человек в части принимаемых им решений будет некомпетентен.
Здравствуйте, StanislavK, Вы писали:
SK>А кто сказал, что они были бестолковые? Все умнейшие люди и знают свое дело. Но дело не в этом. И с хорошими аналитиками да, не хуже, в большистве случаев. Глобальная проблема в том, что очень сложно контролировать то, что как-бы работает — аналитики анализируют, тестеры тестируют, программисты программируют, все вроде заняты. А вот тут фигак, нет больше тестеров и оказывается что, вау, хз, чем они большей частью занимались — продукт можно делать с там же качаеством просто написав чуть больше тестов, чуть больше думая головой и гоняя автоматические инграционные тесты. С аналитиками та же фигня.
А если наоборот? Я вот вижу какой объем работы делают мои PM и Product Owner. И я прекрасно понимаю, что без них все это свалитлось бы мне на голову и я бы утонул во всей этой фигне с головой. Но если заказчик один или продукт вообще коробочный, да работают над проектом полтора разработчика, то да, тут можно и без этих людей.
