Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Последние темы форума

Показать новые сообщения »

Почтовая рассылка

Подписчиков: 6314
Последний выпуск: 19.06.2015

Взаимозаменяемость сотрудников

65K
07 февраля 2012 года
FiloXSee
18 / / 01.07.2011
Написал статью о проблемах при создании ПО. Одна из таких проблем - это то, что сотрудники не взаимозаменяемые. Это осложняет планирование, т.к. некоторые задачи могут решить только конкретные люди. В статье я попытался рассказать в чем именно проблема и как ее можно решать.

Вот эта статья:
http://itw66.ru/blog/application_development/591.html

Что вы думаете по этому поводу? Какие еще есть практики снижения зависимости проекта и компании от конкретных сотрудников?
1
08 февраля 2012 года
kot_
7.3K / / 20.01.2000
после
"Есть такой экономический закон: спрос (и часто цена) на товар растет, при снижении стоимости товаров дополнителей."
читал по весьма по диагонали, автор похоже является хорошей иллюстрацией того, что не все можно "взаимозаменять". Например написать хорошую статью и очертить проблему - тоже уметь надо. А если не умеешь - то получаются вот такое.
Хочу заметить, что описанные автором проблемы типа
Цитата:
Чем больше человек делает, тем больше проект становится от него зависим


решаются не столько мифической "взаимозаменяемостью" сколько нормальной организацией рабочего процесса и четким пониманием областей ответственности. и т.д.
На заметку юному автору - прежде чем изобретать велосипед - не плохо бы хотя бы прочесть что вообще об этом писали до тебя - если уж совсем отсутствует практический опыт участия в больших проектах.
В целом статья - копипаста нипрошто.

262
08 февраля 2012 года
Ramon
1.1K / / 16.08.2003
Цитата: kot_

На заметку юному автору - прежде чем изобретать велосипед - не плохо бы хотя бы прочесть что вообще об этом писали до тебя - если уж совсем отсутствует практический опыт участия в больших проектах.
В целом статья - копипаста нипрошто.


Имено этим то аффтор и знаменит, и им же доставляет =^_^=

1
08 февраля 2012 года
kot_
7.3K / / 20.01.2000
а так я набижал оказывается на известную личность :) видимо мне это чудо еще на глаза не попадалось. но темку надо бы в юмор.
341
08 февраля 2012 года
Der Meister
874 / / 21.12.2007
А что, кто-то не пишет документацию, не юзает вики и багтрекер, не устраивает планёрки при работе в команде?
Или это детская статья?
Да, и причём тут "взаимозаменяемость"? Название совершенно не отражает сути: я, например, предположил, что речь пойдёт об преимуществе сборной первоклашек села Заветы Ильича перед Манчестер Юнайтед или тип того.
296
08 февраля 2012 года
koodeer
1.2K / / 02.05.2009
Глянул статью.

По ходу чтения я задавался теми же вопросами, что и Der Meister. Дальше автор вроде как дал на них ответы, но... всё это до того затаскано и всем известно, что стоило ли писать?

Тут я хотел бы много написать про автомобили, раз уж они упомянуты в статье, но ограничусь лишь этим: Форд вовсе не создавал конвейер. В других отраслях промышленности конвейерное производство вовсю уже применялось. Генри Форд лишь первым применил конвейер в автомобилестроении.

И это, где рациональное зерно статьи? Где новые предложения в разработке ПО?

От себя предложу (на правах рекламы): DSL рулят! Не нужно писать тонны императивного кода, малопонятного и сложного в сопровождении, если можно декларативно описать то же самое кратким и выразительным предметно-ориентированным языком.
Короче, тут идут дифирамбы Nemerle :) (ну и другим языкам с метапрограммированием).
65K
09 февраля 2012 года
FiloXSee
18 / / 01.07.2011
Цитата: Der Meister
А что, кто-то не пишет документацию, не юзает вики и багтрекер, не устраивает планёрки при работе в команде?



Да, не все любят. Хитрость в том, что часто думают, что зря тратят на нее время. На самом же деле, если над проектом работают много людей, то написание подобной документации нужно делать обязательно, потому что оно сэкономит кучу времени. Нужно просто написание документации делать частью задачи. Нет документации - задача не выполнена.

Приведу один пример. Для разработки игры Sega Rally были написаны внутренние документы художникам о том, как и что нужно делать. Например документ по созданию машины: там расписано, какие должны быть метрики, технологии которыми можно пользоваться, сколько должно быть полигонов, как нужно текстурировать, в каких форматах хранить данные, как экспортировать и т.п. Там даже были расписаны временные сроки выполнения каждой детали. Это было написано еще до того, как что-то было сделано. А потом этот документ мог быть роздан всем (включая аутсорсеров) и можно было ожидать не только получение машины на выходе, соответствующей всем формальным критериям, но и создание ее в значительно меньшие сроки. Художникам не нужно думать как делать нечто - все уже расписано. Художникам нет нужды отвлекать лидов вопросами по процессу. Нет проблем с полигонажем или неправильной разверткой текстур.

В моей практике часто не так. Если есть задание сделать 20 машин, то садят например 3-х художников и они начинают делать одновременно. Постоянно бегают с вопросами. Все привыкли пользоваться разными инструментами (в Maya одно и тоже можно сделать кучей разных способов). Дать одному художнику дорабатывать работу другого бывает очень сложно из-за различия стилей (программисты не любят править чужой код, а художники могут просто не уметь дорабатывать чужое). И все это от того, что менеджеры не посчитали нужным дать в начале задание люду разобраться в теме и написать документацию о том, как и что нужно делать. А потом проконтролировать, что все ей пользуются.

Вывод: написание внутренней документации о процессе разработки может существенно экономить силы и время исполнителей, особенно если исполнителей много и много однотипной работы (сделать 100 зданий, сделать 100 деревьев, сделать 50 машин и 20 уровней). Может конечно и не экономить, если ее будут писать для галочки и складывать на полку, а не как внутренний устав разработки. Важно правильно к этому относиться.

Цитата: Der Meister
Да, и причём тут "взаимозаменяемость"?


Это цель, хотя не абсолютная. Но если на проекте есть человек который делает нечто, особенно организационное и с его уходом никто это повторить не сможет (например он в одиночку настраивал сервер и ни кто не знает ни паролей ни деталей), то написание документации по этому вопросу - обязательная норма. На практике часто этим пренебрегают, а потом мучаются, когда человек, например в больницу попал, а срочно нужно что-то сделать.

341
09 февраля 2012 года
Der Meister
874 / / 21.12.2007
Цитата: FiloXSee
В моей практике часто не так. Если есть задание сделать 20 машин, то садят например 3-х художников и они начинают делать одновременно. Постоянно бегают с вопросами. Все привыкли пользоваться разными инструментами (в Maya одно и тоже можно сделать кучей разных способов). Дать одному художнику дорабатывать работу другого бывает очень сложно из-за различия стилей (программисты не любят править чужой код, а художники могут просто не уметь дорабатывать чужое). И все это от того, что менеджеры не посчитали нужным дать в начале задание люду разобраться в теме и написать документацию о том, как и что нужно делать. А потом проконтролировать, что все ей пользуются.

Вы щас описываете ситуацию, когда в коллективной работе вообще нет никакой системы.

262
09 февраля 2012 года
Ramon
1.1K / / 16.08.2003
Цитата: Der Meister
Вы щас описываете ситуацию, когда в коллективной работе вообще нет никакой системы.



Система "без системы" это тоже система =^_^=.

Знаете кого-то, кто может ответить? Поделитесь с ним ссылкой.

Ваш ответ

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог