Взаимозаменяемость сотрудников
Вот эта статья:
http://itw66.ru/blog/application_development/591.html
Что вы думаете по этому поводу? Какие еще есть практики снижения зависимости проекта и компании от конкретных сотрудников?
"Есть такой экономический закон: спрос (и часто цена) на товар растет, при снижении стоимости товаров дополнителей."
читал по весьма по диагонали, автор похоже является хорошей иллюстрацией того, что не все можно "взаимозаменять". Например написать хорошую статью и очертить проблему - тоже уметь надо. А если не умеешь - то получаются вот такое.
Хочу заметить, что описанные автором проблемы типа
решаются не столько мифической "взаимозаменяемостью" сколько нормальной организацией рабочего процесса и четким пониманием областей ответственности. и т.д.
На заметку юному автору - прежде чем изобретать велосипед - не плохо бы хотя бы прочесть что вообще об этом писали до тебя - если уж совсем отсутствует практический опыт участия в больших проектах.
В целом статья - копипаста нипрошто.
На заметку юному автору - прежде чем изобретать велосипед - не плохо бы хотя бы прочесть что вообще об этом писали до тебя - если уж совсем отсутствует практический опыт участия в больших проектах.
В целом статья - копипаста нипрошто.
Имено этим то аффтор и знаменит, и им же доставляет =^_^=
Или это детская статья?
Да, и причём тут "взаимозаменяемость"? Название совершенно не отражает сути: я, например, предположил, что речь пойдёт об преимуществе сборной первоклашек села Заветы Ильича перед Манчестер Юнайтед или тип того.
По ходу чтения я задавался теми же вопросами, что и Der Meister. Дальше автор вроде как дал на них ответы, но... всё это до того затаскано и всем известно, что стоило ли писать?
Тут я хотел бы много написать про автомобили, раз уж они упомянуты в статье, но ограничусь лишь этим: Форд вовсе не создавал конвейер. В других отраслях промышленности конвейерное производство вовсю уже применялось. Генри Форд лишь первым применил конвейер в автомобилестроении.
И это, где рациональное зерно статьи? Где новые предложения в разработке ПО?
От себя предложу (на правах рекламы): DSL рулят! Не нужно писать тонны императивного кода, малопонятного и сложного в сопровождении, если можно декларативно описать то же самое кратким и выразительным предметно-ориентированным языком.
Короче, тут идут дифирамбы Nemerle :) (ну и другим языкам с метапрограммированием).
Да, не все любят. Хитрость в том, что часто думают, что зря тратят на нее время. На самом же деле, если над проектом работают много людей, то написание подобной документации нужно делать обязательно, потому что оно сэкономит кучу времени. Нужно просто написание документации делать частью задачи. Нет документации - задача не выполнена.
Приведу один пример. Для разработки игры Sega Rally были написаны внутренние документы художникам о том, как и что нужно делать. Например документ по созданию машины: там расписано, какие должны быть метрики, технологии которыми можно пользоваться, сколько должно быть полигонов, как нужно текстурировать, в каких форматах хранить данные, как экспортировать и т.п. Там даже были расписаны временные сроки выполнения каждой детали. Это было написано еще до того, как что-то было сделано. А потом этот документ мог быть роздан всем (включая аутсорсеров) и можно было ожидать не только получение машины на выходе, соответствующей всем формальным критериям, но и создание ее в значительно меньшие сроки. Художникам не нужно думать как делать нечто - все уже расписано. Художникам нет нужды отвлекать лидов вопросами по процессу. Нет проблем с полигонажем или неправильной разверткой текстур.
В моей практике часто не так. Если есть задание сделать 20 машин, то садят например 3-х художников и они начинают делать одновременно. Постоянно бегают с вопросами. Все привыкли пользоваться разными инструментами (в Maya одно и тоже можно сделать кучей разных способов). Дать одному художнику дорабатывать работу другого бывает очень сложно из-за различия стилей (программисты не любят править чужой код, а художники могут просто не уметь дорабатывать чужое). И все это от того, что менеджеры не посчитали нужным дать в начале задание люду разобраться в теме и написать документацию о том, как и что нужно делать. А потом проконтролировать, что все ей пользуются.
Вывод: написание внутренней документации о процессе разработки может существенно экономить силы и время исполнителей, особенно если исполнителей много и много однотипной работы (сделать 100 зданий, сделать 100 деревьев, сделать 50 машин и 20 уровней). Может конечно и не экономить, если ее будут писать для галочки и складывать на полку, а не как внутренний устав разработки. Важно правильно к этому относиться.
Это цель, хотя не абсолютная. Но если на проекте есть человек который делает нечто, особенно организационное и с его уходом никто это повторить не сможет (например он в одиночку настраивал сервер и ни кто не знает ни паролей ни деталей), то написание документации по этому вопросу - обязательная норма. На практике часто этим пренебрегают, а потом мучаются, когда человек, например в больницу попал, а срочно нужно что-то сделать.
Вы щас описываете ситуацию, когда в коллективной работе вообще нет никакой системы.
Система "без системы" это тоже система =^_^=.