Очень рекомендую на тему создания эффективных компаний в которых хочется работать почитать пост в блоге Сергея.
Считаю весьма полезной книгу Адизеса про жизненный цикл компании. ИМХО «биполь адекватности» будет наиболее заметно проявляться в фазах от «Ухаживания» до «Признаки старения», а вот демонизация отношений появится ярко в следующих фазах приближения к смерти, особенно в «Салем-Сити».
1) Прямой ответ не дам по объективным причинам, косвенный такой — в компании первого типа довольно высокие результаты на рынке и относительно низкая текучка кадров. Если результаты высокие и текучка высокая — скорее всего мясорубка.
2) Конечно. В компаниях второго типа нередко храбро держат оборону «биполи адекватности» — департаменты или отделы, с сильными и позитивными руководителями. Пока они прикрывают подчиненных, работать можно.
Спасибо. По секрету, тсс..., если вы видите что топы, как бы мягко это сказать, замедляют процесс развития компании и тролят — их можно подставить и лично встретится с первым лицом компании. Вас либо быстро уволят за это — либо вы станите топом и воплотите здоровые идеи в жизнь. :-)
Но есть момент. Иногда попадаются группы людей одного уровня — средне-низкого, спаянные тусением и взаимным раздолбайством. И им бесполезно что-либо доказывать, показывать, объяснять — в этом случае нужно решать проблему на уровне выше.
Согласен. Не верю, что без системного подхода можно браться за сколь серьезные проекты. В статье старался описать выстраивание системы управления — открытой и честной. Ну сделали мне спринт фекалийного качества — давайте собираться и смотреть в чем дело, разбирать полеты.
Погодите. Аналитик описывает бизнес-процессы и логику и работает на уровне выше. Разработчик эти вещи переводит на уровень ниже — уровень классов и таблиц БД. Односторонний процесс.
Да, если аналитик попадется тупой или менеджер глупый — то тут разработчики могут реально посоветовать дело :-)
Ну да, по всем оценкам на покере релиз на коробке должен завершиться за 4 спринта — но, черт, появляются спринты под названием «Стабилизация», «Углубленное тестирование», «Исправление багов», «Тестирование после исправления багов», «Разгон системы, зависшей после исправления багов» — я совершенно серьезно. И поэтому тут и 4 и 6 месяцев и… год может пройти :-)
Я понимаю вас. Создается техническая мафия, которая вяло, ковыряясь пальцем в носу, поделывает пописывает проекты. Конечно, когда приходит управленец, который снизу подсвечивает безответственность и разгильдяйство — его не любят, особенно если получают неплохие деньги за процесс, который и так идет. :-)
Я тут про php писал. ТЗ… хотелось же по хорошему, по человечески, по Agile методологии.
Если коробка то тут можно аккуратно без большого ТЗ. В ТЗ вписываем только то, что нужно в этой коробке доделать/переделать. Если коробка имеет документацию, то на нее ссылки из ТЗ.
Поэтому показываю, что за 4 месяца можно и магазин написать и ТЗ большое не делать :-)
Если программист сможет разобраться в коробочном продукте — он приобрает хороший системный опыт выживания в море кода. Не все это могут, некоторые ломаются и остаются на уровне пары тройку классиков.
Под юникс пишут же софт — приспосабливаются :-) А что, юникс правильно написан на ООП — нет.
Под j2ee чтобы писать правильно нужно дофига изучить готового кода и прочитать массу книг. Своего рода тоже коробка.
Я лично знаю много отличных разработчиков, владеющих ООП и паттернами проектирования, которые смогли разобраться и научились уважать коробки. Мало того, коробочная разработка приносит ребятам неплохой доход, в отличие от крутого ООП… для души.
Еще иногда нужно описать алгоритмы, например расчета скидок. Можно в виде Activity диаграммы, можно через State диграмму, можно в ТЗ словами конечно.
Иногда разработчики модели не досматривают до конца :-) Кардиналити реализуют не так, как нарисовано. А еще страшнее, шепотом — когда дело доходит до ссылочной целостности на уровне приложения — у меня один раз спросили перед сдачей проекта несколько лет назад в другой компании, а что это?
Еще «радует», когда вы с аналитиком увидели систему целиком и формально и точно ее описали — а разработчики… отчаянно тупят и вы, сопротивляясь врожденному гуманизму, вынуждены толкать «мозги нации» в з… цу, прошу прощения
Вы бизнес с командой разработки ведете, что-ли? Как можно о чем то договариваться с командой? Люди в команду приходят и уходят. За качество проекта изнутри отвечает либо главный разработчик компании либо техдир, а за весь продукт в целом отвечает руководитель компании. Эджайл тут не причем.
Владельца продукта должны страховать эксперты по качеству, безопасности, производительности — в 80% команд, по моему опыту, вообще об этом никто не задумывается.
Считаю весьма полезной книгу Адизеса про жизненный цикл компании. ИМХО «биполь адекватности» будет наиболее заметно проявляться в фазах от «Ухаживания» до «Признаки старения», а вот демонизация отношений появится ярко в следующих фазах приближения к смерти, особенно в «Салем-Сити».
2) Конечно. В компаниях второго типа нередко храбро держат оборону «биполи адекватности» — департаменты или отделы, с сильными и позитивными руководителями. Пока они прикрывают подчиненных, работать можно.
Одна из целей статьи — объективно показать PO когда коробочное решение действительно может принести ему выгоду. А когда не может.
Список успешных решений на коробках можете посмотреть в моем портфолио — я не хочу грузить маркетинговым булшитом уважаемых коллег :-)
Мемы и другие техники манипулирования сознанием — не приветствую. Предпочитаю делиться личным опытом и наблюдениями.
Да, если аналитик попадется тупой или менеджер глупый — то тут разработчики могут реально посоветовать дело :-)
Если коробка то тут можно аккуратно без большого ТЗ. В ТЗ вписываем только то, что нужно в этой коробке доделать/переделать. Если коробка имеет документацию, то на нее ссылки из ТЗ.
Поэтому показываю, что за 4 месяца можно и магазин написать и ТЗ большое не делать :-)
Под юникс пишут же софт — приспосабливаются :-) А что, юникс правильно написан на ООП — нет.
Под j2ee чтобы писать правильно нужно дофига изучить готового кода и прочитать массу книг. Своего рода тоже коробка.
Я лично знаю много отличных разработчиков, владеющих ООП и паттернами проектирования, которые смогли разобраться и научились уважать коробки. Мало того, коробочная разработка приносит ребятам неплохой доход, в отличие от крутого ООП… для души.
Иногда разработчики модели не досматривают до конца :-) Кардиналити реализуют не так, как нарисовано. А еще страшнее, шепотом — когда дело доходит до ссылочной целостности на уровне приложения — у меня один раз спросили перед сдачей проекта несколько лет назад в другой компании, а что это?
Владельца продукта должны страховать эксперты по качеству, безопасности, производительности — в 80% команд, по моему опыту, вообще об этом никто не задумывается.