Нерешаемая проблема организации. Правдивая история

Оформила Татьяна Красных


Нерешаемая проблема организации. Правдивая история 

al_mt  
Сей топик пишу "на горячую", пока не остыл. Тема достойна статьи, но  объёмом не выйдет.                                                       
                                                                                                  
День первый                                                              
1. Менеджер А ставит задачу. А не технарь, но хороший менеджер. 
Задача поставлена хорошо, но технически недостаточно чётко.                     
2. Менеджер Б пристёгивает к группе удалённого программиста П, 
мотивируя это нехваткой людей в отделе.                                  
3. Поскольку задача делается с нуля, а людей и правда не хватает, то я принимаю это без возражений.                                             
4. Я собираю своих программистов на МШ для составления чёткого ТЗ и хотя бы исходной структуры 
реализуемого функционала. По итогам МШ, мы  приступаем к работе.                                                     
5. При общении меня с П, возникает вполне ожидаемый "танец тушканчиков". 
Это дело привычное, потому я купирую инициативные порывы П, 
выделив ему независимый фрагмент задачи.                              
                                                                                                  
День второй                                                              
1. Реализована часть потрохов системы, информация рассылается сотрудникам.                                                             
2. Произвожу перераздачу задач, на основании проделанной работы          
3. Менеджер А выдаёт задачу верстальщику - сотруднику другого отдела 
и ставит об этом меня в известность.                                       
4. К концу дня когда выполнена некая часть работы, я принимаю выполненную вёрстку.                                                     
5. ОБНАРУЖЕНА ПРОБЛЕМА: желая выполнить работу наилучшим образом,   
верстальщик создал библиотеку стилей,... которая разумеется вызвала конфликт имён 
с уже существующей в проекте 
Потеря - дневная работа верстальщика.                                                     
*Даже знать о существовании наличной библиотеки верстальщик не обязан,   
а менеджер не знает, что это такое 
                                                                                                  
День третий                                                              
1. Верстальщик озадачен и роет свои исходники с целью массового разруления конфликтов имён 
(несколько десятков)                          
2. При попытке первой сборки ничего не работает                          
3. Пока мы колотимся головами об клавиатуру, с целью заставить работать хоть чего-нибудь, 
начинает нервничать А, каковому сегодня нужно представить презентацию...                                               
4. Я выясняю, что ТЗ менеджера было понято нами (мною в первую очередь) не верно, 
в результате приоритеты были расставлены так, что мы не успеваем                                                                 
5. Перерасставляю задачи, "плечом к плечу, могучим усилием"              
проворачиваем это дело и со скрипом получаем набор декоративных страниц для презентации                                                          
6. При включении в проект фрагмента, написанного П, включается режим "танца тушканчиков". 
За неимением времени, я попытался надавить на человека дисциплинарно, 
но на удалёнке такие номера не прокатывают. 
В результате потеряно около часа времени, но в критичный момент.           
7. Плюю на всё. Непосредственно подконтрольных программистов перевожу на длинные задачи 
и приказываю не отвлекаться на правокации менеджеров.  
П перевожу в режим быстрей-быстрей, сам включаюсь в работу по декорированию.                                                           
8. Нечто ужасное, показывается на экране перед аудиторией, и я счастлив что этого не вижу...                                                     
                                                                                                  
Думаю, здесь присутствующие управленцы повидали гораздо более экстремальные ситуации, 
но я речь свою веду о:                           
1. Факторах, исходно предопределивших возникновение проблем              
2. Проявлении проблем                                                    
                                                                                                  
Факторы:                                                                 
1. Цейтнот                                                               
2. Недостаточная чёткость сформулированного ТЗ                           
3. Включение в группу непритёртого человека, да ещё на удалёнке          
                                                                                                  
Проявления:                                                              
1. Неверно понятое ТЗ, вызвало неверную расстановку приоритетов          
2. Нестык между добросовестными представителями разных функциональных подразделений, 
вызвал необходимость двойной работы                       
3. Новый человек, вызвал проблемы, отстаивая своё "место в иерархии"     
                                                                                                  
Заметьте, что каждый фактор в отдельности отнюдь не проблема, для всех есть отработанные методики 
преодоления, но наложившись друг-на-друга,  они могли оказать фатальное воздействие. 
Причём сочетание этих факторов, вызвало резкое увеличение "удельного веса" проблем, которые в  
иной ситуации были бы незаметны: недостаточное быстродействие компьютеров, 
недостаточная пропускная способность ICQ, как средства общения и т.п.                                                           

Михаил Ермак  
У тебя проблема в contingency* - при отработке сроков ты не заложился  
(а ведь предполагал, зная наличие удаленного П) на танец тушканчиков 
и communication c другим отделом.                                          

Вторая проблема - твой менеджер А не получил на утверждение план проекта - с указанными закладками 
на проблемы - соответственно, ты дезориентировал его в плане сроков и подставил себя.                     
                                                                                                  
20 проц континдженси лечило бы тебя.                                     

Vasilisk   
Мне лично не очень понятен один момент. 
Менеджер Б задачу не ставил и в дальнейшем нигде не фигурирует. 
Какое он имеет отношение к подбору команды под эту задачу 
и почему он вообще имеет к ней отношение?         

Михаил Ермак 
У них система местного разлива - ресурсами ведает один менеджер, проект ведет другой.                                                            
Менеджеру Б пох на проект - он ведает ресурсом программеров.             

Vasilisk   
хреново, что тут сказать... А отмазаться от ненужного ресурса никак?     
Как вообще привлечение П повлияло, хоть насколько-то срок разработки сократился, 
чем если бы своими силами всё делали? Если нет, то идеальным был бы жесткий игнор.                                          

Михаил Ермак
Насколько я понимаю ситуацию - у конторы нет достаточно наличных ресурсов. 
Стандартное решение в таких случаях - привлечь контрактора - стороннего работника.                                                    
Это имеет плюсы и минусы, но является самым быстрым ответом на проблему.                                                                
                                                                                                  
С точки зрения менеджера А - срок пофигу, если бы автор темы довел бы до менегера правильные сроки 
с учетом континдженси, то проблем бы не возникло ни у него ни у менеджера. 
А так, для менеджера нет хуже ситуации, когда он до последнего уверен в том, 
что все ок, ресурсы выделены, работа идет и вдруг перед презентацией полный швах потому что  
- его team lead решил покрыть ошибку планирования на своем уровне, 
и не справился, потому что уровень не его.                                    
                                                                                                  
У нас обычно в таких случаях гонят с работы. 
Потому что, это должно быть на подкорке - любая проблема в момент ее рефлексии обязана быть     
донесена до начальника. 
После этого, это уже не твоя проблема.           
                                                                                                  
Я на месте А, узнай о проблемах вовремя - решил бы ее. 
А за час до презентации это уже полный Щорс...                                       

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

Nick Sakva 
Михаил Ермак писал:                                 
У тебя проблема в contingency* - при отработке сроков ты не заложился ...                                                        

Отработке чего?                                                          
Если я правильно понял изложенную историю, задача ставилась так.         
"Результат нужен послезавтра не позже второй половины дня."              
                                                                                                  
Нет, скорее так.                                                         
"Результат НУЖЕН ПОСЛЕЗАВТРА! Не позже второй половины дня!!!"           
                                                                                                  
Торговаться в таких условиях можно только об объеме результатов, а не о сроках. 
Как только ты заикаешься о сокращение объема (ради contingency), тебе сразу пристегивают 
верстальщика и тушканчика.         
                                                                                                  
Если это "разбор полетов", то я основной прокол, на который у меня мог бы своевременно сработать 
"автоматический alarm", усматриваю тут:        
                                                                                                  
3. Менеджер А выдаёт задачу верстальщику - сотруднику другого отдела и ставит об этом меня 
в известность.                                       
                                                                                                  
Слеует ожидать, что он все сделает не так.                 

Михаил Ермак  
Ник, чушь(с)                                                             

При такой постановке вопроса менеджера надо гнать. 
Ибо в такой постанове вопроса виноват прежде всего он.                               
                                                                                                  
Необходимо сказать сразу - сроки невыпонимы, работу мы выполнять будем,  
но результата не будет, потому что...                                    
                                                                                                  
Если очень хочется, можно сказать что все готовы работать овертайм при двойной оплате. 
Ну полуторной.                                           
                                                                                                  
Во всех остальных случаях виноват будет афтар поста.                     

Nick Sakva  
Наши менеджеры настолько освоили "стратегию чуда", что такая постановка правило, а не исключение. 
Более того, "чудо", как я понимаю, было вполне возможно, если бы не недооценка 
"крутости" верстальщика.                                      

Winter   
Что такое "танец тушканчиков"?                                           

Михаил Ермак 
Ник, это все действительно ужасно, потому что нельзя так насиловать Мироздание по мелочам.                                                   

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

Farit  
Хмм...                                                                   
Цейтнот - не фактор, предопределивший возникновение проблемы, а собственно проблема и есть. 
А фактором здесь является:                   
1. Я собираю своих программистов на МШ для составления чёткого ТЗ и хотя бы исходной структуры 
реализуемого функционала. По итогам МШ, мы приступаем к работе.                                                     
Вы приступили к работе по итога МШ, на не по итогам согласования и подписания четкого ТЗ                                                    
                                                                                                  
2. При общении меня с П, возникает вполне ожидаемый "танец тушканчиков". 
Это дело привычное, потому я купирую инициативные порывы П, выделив ему независимый фрагмент задачи.                              
Как вообще возникли у П эти "порывы"? 
Что удаленщику дают всю задачу, а не ее фрагмент?                                                          
                                                                                                  
Тот же вопрос по верстальщику. Если пересекаются области компетенции -   
границы должны быть промаркированы особо.                                
                                                                                                  
Третий фактор - Включение в группу непритёртого человека, да ещё на удалёнке                                                                 
В каком-то смысле в этом суть - притертость в большинстве случаев означает (в том числе) 
"я обрисую ему задачу в самых общих чертах, а он сам врубится".                                                           
То есть тут - неявное противопоставление команды притертой и команды,    
скажем так, формальной. 
Первый тип страшно любят менеджеры - они приступают к работе тотчас по получении самого общего 
представления о том, что должно быть сделано, и на выходе всегда представят "хоть что-то", 
что потом так или иначе доведут.                                
                         
Вторые могут довести до исступления требованием формализации ТЗ,         
утверждения спецификаций, выяснением структуры и полномочий, вышибанием потребных ресурсов и пр. 
Но реально большой проект потянут, вероятно, только они.                                                              
Во всяком случае мой опыт именно о том и говорит.                        

Nick Sakva
Не совсем уверен, насколько мои комментарии соответствует ситуации al_mt, 
но вообще-то все это настолько типично...                         

Farit писал:                                        
Вы приступили к работе по итога МШ, на не по итогам согласования и подписания четкого ТЗ                                 
                                                                                                  
Согласование и подписание четкого ТЗ потребует не меньше трех дней. 
К тому времени данная работа вообще потеряет смысл.                        
                                                                                                  
Цитата:                                                              
Как вообще возникли у П эти "порывы"? Что удаленщику дают всю задачу, а не ее фрагмент?                                            
                                                                                                  
Элементарно. Например.                                                   
"Вы все делаете не так: не тот язык, не та операционка, не те библиотеки, это все давным-давно 
устарело (вариант - это все новомодные ненадежные рюшечки и бантики). 
Либо вы все делаете по-моему, либо я все сделаю, как положено (варианты: по-современному, 
по стандарту, абсолютно надежно и т.п ), а уж как вы это интегрируете - ваша проблема."                                                               
                                                                                                  
Цитата:                                                              
Тот же вопрос по верстальщику. 
Если пересекаются области компетенции - границы должны быть промаркированы особо.              
                                                                                                 
Тут ляп уже в самом наименовании. 
По ходу дела выясняется, что "верстальщик" на самом деле "типа веб-програмист" с творческими          
уклоном... На самом деле тот же "танец", причем там, где его не ждали.   
А зря! Это как раз включился тот самый "механизм компенсации", о котором тут пишет Михаил.                                                
                                                                                                  
Михаил Ермак писал:                                 
Вот поэтому Америка и выиграла индустриальный мир. 
Они обходятся без чудес там, где их не требуется.                        
                                                                                                  
Разумеется. Это именно "аграрный" стиль работы в условиях зоны рискованного земледелия.                                                 
Если урожай созрел - навались, хватай больше, тащи дальше, пока солнышко, пока не дождь не пошел, 
пока града не было... 
Отдыхать будем всю зиму, когда все равно почти ничего делать нельзя, только тепло беречь. 
Планировать можно сколько угодно - обстоятельства (например погода) все равно пошлют все планы 
подальше и зима все равно наступит неожиданно. 
Кстати, где она, зима? Так ведь и не наступила.              
                                                                                                  
Видимо все это у нас очень глубоко прошито в подкорку, почему возможно, кстати, 
из русских редко получаются хорошие менеджеры. С индустриалом это очень плохо совместимо. 
Но вот в условиях постгосударственного хаоса это как раз может дать шанс.                                       

al_mt  
1. Разумеется получив менеджерское ТЗ был выдан прогноз по срокам - месяц 
2. Разумеется был урезан функционал, после чего прогноз - неделя.       
3. Пристёжка верстальщика - это нормальная практика. 
Проблема в том,  что не было заложено время на исправление возможных ошибок. 
Сам верстальщик ни каких ошибок не допустил. Он не учёл специфику ситуации.  
Моя ошибка, что я до него этот момент не донёс, но именно такая ситуация сложилась впервые. 
Однако же, будь у меня месяц, день  потерянной работы составил бы 3% а так получилось 30%!!!                 
4. "Танец тушканчиков" - термин обозначающий ритуал притирки программистов перед началом 
совместной работы. Может занимать от 3-х суток до месяца 
5. Относительно менеджерского ТЗ. Менеджеры не знают техники. 
Хорошие менеджеры, знают, что они не знают техники 
Менеджер А - "хороший менеджер". 
Обычно мы решаем задачу так: 
а) выдаётся общее ТЗ 
б) мы самовырабатываем конкретное ТЗ и возвращаем менеджеру на утверждение 
в) повторить до получения нормального ТЗ. 
Однако в данном случае, времени на согласование не оставалось 
и я приказал начинать работы не дожидаясь окончательного ТЗ. 
Когда же спустя сутки (нормальный срок для одного такта согласования) пришла коррекция ТЗ, 
выяснилось, что ТЗ у нас правильное, а вот с очерёдностью ввода модулей в эксплуатацию я ошибся.  
Не будь цейтнота - это вообще не имело бы значения 
                                                                                                  
Вывод: каждый из перечисленных факторов сам по себе преодолим и есть наработанные методики. 
Более того!                                       
Если убрать фактор "цейтнот", то все остальные проблемы - не проблемы.   
Если убрать нечёткое ТЗ, то все остальные проблемы - не проблемы!        
Если убрать непритёртость команды, то выигрываем немного, но в самый критичный временной момент, 
а также выигрываем время необходимое на преодоление "порога входа".                                              
И только собрание факторов вместе потребовало неимоверных усилий, 
чтобы добиться хотя бы минимального результата. 
По сравнению с обычным режимом работы КПД упал хорошо если на порядок...                        

Генрих   
Пост государственный хаос..."смело" сказано. 
Проблема большею частью не "ментальная", а инструментальная. 
Ну ни... мы ещё не научились пользоваться нужными инструментами в наших условиях... дерём   
полную кальку "... знает с кого", а потом удевляемся полученному результату. 
Совсем забыли, блин, про напильник. Беларучки... 

Гришнов    
1. Очень важно понимать своего начальника. Понимать с полуслова.         
Желательно - вообще без слов: улучшение вертикальной коммуникации на 1-2 ступени вверх творит чудеса.                                         
2. Никогда не соглашайтесь со сроками "завтра-послезавтра". 
Скажите: будем делать", но не говорите "сделаем".                                 
                                                                                                  
Понимаю, что сказанное - фантастика. Но тем не менее...                  

al_mt  
...именно, что фантастика

Nick Sakva    
Цитата:                                                              
3. Пристёжка верстальщика - это нормальная практика. ... 
Сам верстальщик никаких ошибок не допустил. Он не учёл специфику ситуации. 
Моя ошибка, что я до него этот момент не донёс, но именно такая ситуация сложилась впервые.                             
                                                                                                  
Вот тут я не согласен. Именно "по принципу компенсации" какая-то "ситуация" в этом месте более чем 
вероятна. На мой взгляд ошибка не столько в "недоносе специфики ситуации", 
сколько в недостаточной паранойе по поводу того, что в этом месте обязательно что-то должно      
пойти не так. Именно потому, что потеря дня - это 30%.                   
                                                                                                  
Цитата:                                                              
Когда же спустя сутки (нормальный срок для одного такта согласования) пришла коррекция ТЗ, 
выяснилось, что ТЗ у нас правильное, а вот с очерёдностью ввода модулей в эксплуатацию я ошибся.                                                              
                                                                                                  
Вот это как раз я ошибкой не считаю. Опять же, принцип компенсации.      
Если бы очередность ввода модулей целиком и полностью соответствовала ТЗ, 
то через день выяснилось бы, что ТЗ таки ошибочно и порядок все равно надо менять. 
Так что если тут и есть ошибка, то опять лишь неперазаклад на "все равно все будет не так".                            

al_mt   
Верстальщик - не "компенсатор", а "прикомандированный специалист".       
Не тот порядок ввода модулей в эксплуатацию действительно ошибкой не является, 
но именно в данном случае - явился 
                                                                                                  
Перезаклад "всё равно всё будет не так" - это нерушимый закон планирования! 
И в данном случае он тоже использован: в ситуации с неясным ТЗ начаты работы, 
с риском их бесполезности, это повышает вероятность успешного выполнения работы 
за счёт снижения суммарного КПД.                                                                     
                                                                                                  
Корень зла таится безусловно в начальстве менеджера А, которое "даёт нереальные планы". 
Но это настолько очевидно и неисправимо, что даже обсуждать бессмыссленно. 
Тем более, что ГиперМенеджер может и сам принимать решения в условиях форс-мажора.                                
Задача в том, как не взирая на вышеуказанные проблемы, таки решать проблемы. 
В сущности в указанной ситуации достаточно решить 1 (одну!!) из проблем 
и вся ситуация волшебным образом разруливается!               
                                                                                                  
Для меня самым очевидным является копать в направлении повышения эффективности коммуникации 
между менеджерами и прикомандированными специалистами. 
Особенно интересно решить проблему "нечёткого ТЗ". Это сняло бы больше половины проблем.                                        

Farit  
Nick Sakva писал:                                   
Не совсем уверен, насколько мои комментарии соответствует ситуации al_mt, 
но вообще-то все это настолько типично...            

Опишите это тогда (в типичном виде) этот момент со стороны менеджера.    
Потому, что "послезавтра надо делать презентацию, а у нас еще даже ТЗ не сформулировано" 
подозрительно напоминает "но в декабре вдруг наступила зима".                                                         
                                                                                                  
Nick Sakva писал:                                   
Как вообще возникли у П эти "порывы"? Что удаленщику дают всю задачу, а не ее фрагмент?                                
                                                                                                  
Элементарно. Например.                                               
"Вы все делаете не так: не тот язык, не та операционка, не те библиотеки, 
это все давным-давно устарело (вариант - это все новомодные ненадежные рюшечки и бантики). 

Либо вы все делаете по-моему, либо я все сделаю, как положено (варианты:                 
по-современному, по стандарту, абсолютно надежно и т.п ), а уж как вы это интегрируете - 
ваша проблема."                            
                                                                                                  
Опять же, работать по удаленке мне пришлось и как программеру, и как работодателю, 
и эта ситуация мне представляется дикостью. То есть либо ему дают всю работу целиком 
и он сам выбирает, как ее реализовывать,     
либо предельно четко - на пхп, такие-то классы, такие-то библиотеки,     
реализуешь то-то и то-то. Чего тут возбухать мне неясно.                 
То есть мне так задачи ставили я не жужжал, я так задачи ставил, и мне тоже не жужжали.                                                         
Не знаю, может у вас опыт радикально другой - поделитесь.                
                                                                                                  
Nick Sakva писал:                                   
Тут ляп уже в самом наименовании. По ходу дела выясняется, что "верстальщик" на самом деле 
"типа веб-програмист" с творческими уклоном... 
На самом деле тот же "танец", причем там, где его не ждали.                                                               
                                                                                                  
В том-то и дело. По описанию выходит, что над проектом работало три _разных_ группы программистов - 
собственно отдел мт, верстальщик из соседнего и удаленщик, 
и каждая единица делала (либо хотела делать) что-то свое.                                                             

al_mt  
2Farit                                                                   
Дело в том, что приданный программист из нашей фирмы, но из другого офиса. 
Более того, ситуация осложняется тем, что я (фактически начальник) - в провинции, а он - москаль                      
                                                                                                  
Обычно такие проблемы решаются, но в данном случае просто не было времени на притирку.                                                     
Чаще всего мне удаётся убедить подчинённых программистов, что выполняя мои задания, 
они "делают именно то что хотят" 
Но на это нужно время...                                                                 

Farit      
А может проблему переформулировать? И к третьему дню выпустить не какой-нибудь заструганный 
до прозрачности релиз, а простую и нарисоанную на коленке презентацию?                                      
Я такое делал, помнится - когда мне надо было сдавать документы на защиту в Совет 
(то есть получить формальную заверенную справку - от нее отчитывается срок для рассылки 
автореферата и т.п.) и зима действительно наступила внезапно (выяснилось, что ректор по какому-то    
поводу приглашает пару московских членов совета в Уфу, то есть можно было собрать полный 
не напрягаясь с билетами и т.п.), я просто тот же автореферат нарисовал - сделал титульный, 
второй титул, заголовки разделов, а внутрь - полную ахинею, просто кусками навыдирал из          
диссера. Распечатал, положил в прозрачную папку и понес в совет.         
Секретарь приняла, небрежно пролистала, опись составила и справку выписала. 
Все, а через пару дней я папку взял "чтобы еще раз проверить" и вложил уже нормальную распечатку.                                      
Менеджеры играют в свои игры, не думаю, что для них через три дня нужна работающая программа. 
Им через три дня нужен отчет. Вот на отчет и надо налегать 

Nick Sakva 
Типично примерно следующее. Начало года (ага!), распределяются заказы на год. 
Менеджер во вторник нащупал выгодный заказ, но вынужден (по "правилам игры") утверждать, 
что "у нас большой задел и опыт". Причем он не врет, все так, просто "все разобрано", 
а у заказчика своя специфика. Заказчик просит: "Ну покажите, что у вас есть. Желательно на  
этой неделе, потому что в понедельник я улетаю в Москву на Совещание Как Раз По Этому Вопросу..."                                             

Farit  
Знакомо. Решается как раз так, как я описал (все силы на презентацию и убеждение заказчика, 
реальная работа над задачей начинается после получения контракта).                                                    
То есть здесь я не вижу, зачем нужна вообще программистская работа, да еще и столь жесткая. 
Пиар, исключительно.                                

Nick Sakva  
Для этого нужен очень сильный и самостоятельный пиар-отдел. 
Да и тертый заказчик сейчас на презентацию может и не клевать. "Есть, говорите?      
Покажите какой-нибудь рабочий макет применительно к нашей специфике."    
                                                                                                  
Тут еще вопрос, что быстрее, собрать презентацию, или работающие модули. 
Причем модули впечатляют гораздо больше.                         

al_mt 
1. Под чётким ТЗ я понимаю "документ, чётко описывающий что именно и в какой очерёдности 
необходимо получить". В данном случае менеджером был выдан "документ, 
нечётко описывающий что нужно получить". 
После переработки получился документ, верно отвечающий на вопрос "что сделать", 
но не верно на вопрос "в какой очерёдности".                   
2. О какой другой компенсации?                                           

Farit   
Собрать презентацию быстрее. Если заказчик действительно тертый, то он понимает, 
что за три дня ему никакую реальную специфику не сваяют, то есть требовать это не будет 
(либо будет с четким желанием отсеять - и отсеет). 
Потребовать за три дня рабочие модули может только очень уж наивный заказчик.                                                        
То есть опыт у каждого может быть свой и выводы могут быть любые. 
Мой по данной ситуации вполне однозначен - заказчику нужны не рабочие модули, 
а уверенность в том, что дело поручено компетентному подрядчику. 
Уверенность эта индуцируется не рабочими модулями. И не презентацией, по большому счету. 
Они в этом смысле равны между собой - просто презенташка гораздо проще 
и не имеет долговременных последствий, как торопливое начало большого проекта.                                  

Nick Sakva   
al_mt писал:                                        
2. О какой другой компенсации?                                       

О компенсации в рамках "стартегии чудес", о которой говорил Ермак.       
То есть имеется в виду всякая мистика. 
                                                                                                  
Например если путем "пренапряжения нагрузки на астральные сферы",        
удалось "чудом" состыковать все концы с концами, то будь готов к тому,   
что при доставке отчета в последний момент "к дедлайну" на всех перекрестках 
будет гореть красный свет. 
                                                                                                  
P.S.                                                                     
А за разглашение в рабочее время таких вот "тайн мироздания" ящик, 
в котором хранится нужная мне печать, оказался в критический момент запертым, 
шеф в отъезде, а секретарша на обеде!!! 

Литвинов 
Насколько я понял, ошибка менеджера А была в неправильно выставленных краткосрочных приоритетах 
(если они вообще были выставлены), в неверно нарезанных интервал контроля выполнения задачи 
и в неоднозначном определении того, что, в какое время и где будет считаться нужным        
результатом. 
То есть ему следует поработать над надежностью своих указаний.                                                                

Гришнов   
Генрих писал:                                       
А дэир как работает?... меняешь своё КМ, а в ответ мироздание подгоняет тебе пряники... 
если сделал правильно.          

Просто живёшь в потоке времени, текущем из будущего в прошлое. Джыдай.   
Пример:                                                                  
за пару дней до часа П вы почувствовали, что надо как-то изучить предмет А, 
поговорить с верстальщиком (мотальщиком,точильщиком, бойцом скота и пр...), 
ознакомится с материалами проекта "Ковчег" и пр.         
Такая интуиция вырабатывается.                                           
                                                                                                  
То, что предложено до этого - индустриальные решения.                    
Постиндустриалмзм работает с потоком времени, а не в потоке времени.     

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

Михаил Ермак  
Прочитал написанное за сегодня.                                          
Поскольку большинство постов не в тему, а афтар так и не понял, что получит скоро еще одну 
такую же историю, повторюсь еще раз.              

1. Российская специфика будет оставаться такой ровно до тех пор, пока вы ее будете поддерживать.                                               
                                                                                                  
2. Задача изложенная в теме не требует постиндустриальных техник. 
Это задача давно решена и решение запатентовано и используется.              
                                                                                                  
Есть такое сочетание букв SDLC.                                          
Надеюсь, что оно знакомо. 
Этот стандарт будучи доведенным до заказчика и применяемым в конторах решает большинство проблем.                     
                                                                                                  
Макет (а большего для презентации не нужно) рисуется бизнес аналитиком   
и фронтэнд дизайнером за 2-3 дня легко. 
Такой tool как Axure, например, дает возможность имитировать всю UI активность юзеров минимальными       
усилиями. Большего не требуется. Красивые слова пишет аналист или сам манагер.                                                                 
                                                                                                  
al_mt   
Мгы... В том-то и проблема, что я презентациями не занимаюсь...

Михаил Ермак 
Само собой.                                                              
Если Вы хотите услышать рекомендации, что делать лично Вам, то я уже отвечал: 
минимизировать свою ответственность и передать управление вышестоящему начальнику. 
Более общо - человеку генерирующему нереальные сроки. 
Если ваш А толковый манагер больше ничего не требуется.           
                                                                                                  
Я, в основном, пишу о том, как сделать так, чтобы проекты выпускались регулярно без задержек 
к общему удовольствию рабочей группы и заказчика. 
Если это не вляется целью деятельности конторы, то оттуда надо валить. Чем скорее, тем лучше.                                      

SDLC - это методология.                                                  

У нее есть и плюсы, есть и минусы.                                       
Минусы, в основном, более высокая заявленная стоимость проекта,          
удлиненные сроки на стадии работы с заказчиком.                          
Плюсы - существенное повышение шансов сделать проект вовремя и именно таким, 
каким его заказывали.                                             
                                                                                                  
Это применительно к нашей теме.                                          
                                                                                                  
Про квалифицированные кадры, я на полном серьезе готов прочитать лекцию по SDLC 
и его внедрению для управленческого звена любой россиянской софтверной конторы.                                                      
Потому как "Российская специфика будет оставаться такой независимо от нас. " 
- это подход, не дающий ничего ни мне, ни тем кому можно помочь.                                                       

Чибрикин Илья
Други, не знаю как в других местах, а я вот сейчас на буржуйском газовом проекте 
(оператор - первый среди третьих в общемировом рейтинге) - так тут все ровно то же самое, 
разве что тушканчики танцуя квохчут не по нашему.                                                    
Нет накакой российской или изрильской или какой иной специфики, есть законы Паркинсона 
и их стадийность.                                      

Чибрикин Илья  
По методологии "как сделать так чтобы сделать хоть что-нибудь работающее" 
есть четко прописанная методология ГОСТ 34. 
Оный гост написан слезами тех, кто делал иначе. Честно 

Nick Sakva  
Все новое - хорошо забытое старое... 
                                                                                                  
ГОСТ 34 - это все же специфическое ПО - автоматизированные системы.      
АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ. ГОСТ 34.601-90              
                                                                                                  
Но ЕСПД - это "любое ПО вообще".                                         
СТАДИИ РАЗРАБОТКИ. ГОСТ 19.102-77                                        
                                                                                                  
Теперь смотрим System Development Life Cycle (SDLC) Standards            
                                                                                                  
Что называется, "найдите 10 отличий" или "кто у кого списал?". 
                                                                                                  
- Г-голубчики, -- сказал Федор Симеонович озадаченно, разобравшись в почерках. 
-- Это же п-проблема Бен Б-бецалеля. К-калиостро же доказал, что она н-не имеет р-решения.                                            
- Мы сами знаем, что она не имеет решения, -- сказал Хунта, немедленно ощетиниваясь. 
-- Мы хотим знать, как ее решать.                          

P.S.                                                                     
А на русский SDLC переводится как ЖЦРПО                                  
http://www.s-test.elistel.net/LC/index.htm                               

al_mt  
Боюсь, что все эти ГОСТы, SDLC и возможно ещё какие-нибудь аббривеатуры  
не позволяют решить озвученную проблему:                                 
1. ТЗ нечёткое                                                           
2. Команда "несыгранная"                                                 
3. Времени нет                                                           
                                                                                                  
Я лично пытаюсь копать в сторону п.1 ибо это ИМХО можно решить чисто     
технологическими мерами...                                               

Nick Sakva  
Я ж и говорю, ясно, что эта задача не имеет решения, вопрос в другом: а как ее решать?                               

В сторону п.3. копать практически невозможно.                            
В сторону п.1. по-моему копать безнадежно. 
Таким образом можно снять с себя ответственность, но маловероятно получить удовлетворительный        
результат. 
В данном случае удовлетворительный означает удовлетворяющий хоть кого-то: 
заказчика, начальство или хотя бы самого разработчика.     
                                                                                                  
Поэтому на мой взгляд единственный шанс - копать в сторону п.2. Но да,   
чисто технологическими мерами этот вопрос не решается. 

al_mt 
Чисто фантастическое: п.3. решается "машиной времени" (см. Г.Гаррисон) 
Машины времени не существует, но некоторые функции МВ современная техника выполняет - 
например "полицейская камера", которая начинает снимать до нажатия на кнопку 
                                                                                                  
п.2 для решения этого вопроса, я принимаю меры. 
Заключаются они в том, что я отлавливаю свободных людей из других команд и пристыковываю к      
своим стажёрами на 1-2 задачи. 
Получается эдакая виртуальная команда резервистов. 
Проблема в том, что это сокращает время входа в задачу до дней, а нужно до часов                                                   
                                                                                                  
п.1 это не для отмазки, а для реального убыстрения согласования ТЗ. 
У нас в закрытом (увы, но неизбежно) проекте для совместной разработки была предусмотрена 
фича в виде "стола одновременного рисования и текстообмена", 
правда для локальной сети. Однако сейчас у меня нет аналогичного продукта, 
пригодного для взаимодействия через инет. А было бы в жилу...                                                             

Гришнов  
Если и копать, то только туда: проблемы нужно не решать по мере их бурного возникновения, 
а ликвидировать их источник.                    
Способы: от неформальных контактов (лучший вариант) до лекции Ермака   
(худший, ибо после неё начальство станет верить в чудеса).             

Генрих 
al_mt писал:                                       
Проблема в том, что это сокращает время входа в задачу до дней, а нужно до часов                                              

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

Nick Sakva   
Гришнов писал:                                     
Если и копать, то только туда...

Напомню: п.1 - нечеткое ТЗ.                                            
Четкое ТЗ очень часто само по себе является источником серьезных проблем, 
поскольку опирается на неявное предположение, что хотя бы кто-нибудь - заказчик, исполнитель 
или начальство - способен предусмотреть, что ему будет нужно от работы на момент ее окончания.   
                                                                                                  
Реально такое возможно только в "быстрых" проектах. 
Отсюда возвращаемся к приоритетности п 2 и неизбежности п.3.                  

Farit  
Рассматривался как раз-таки не быстрый, а сверхбыстрый проект. 
То есть как раз тут четкое ТЗ было бы спасением.                          
                                                                                                  
Насчет больших - я не знаю. Их у меня за плечами более десятка. 
Во всех - четкое и строгое ТЗ, календарный план, отчетность по каждому этапу и т.п. 
Все успешно выполнены. Везде заказчик доволен. Как-то это странно слышать...                                                 

Алексей Хрылин 
Во всех проектах с которыми я сталкивался четкого ТЗ никогда не было.  
Такое ТЗ подразумевает наличие со стороны заказчика отличных аналитиков и единого ответственного 
лица принимающего решения. 
Обычно в жизни заказчик имеет хреновых аналитиков, коллективный руководящий разум 
и смутное представление что ему нужно ("сделайте нам хорошо").   

Farit  
Ну, я кажется понял, что говорю в основном с программистами 
Мой опыт касается все же более серьезных вещей, типа САУ или систем диагностики.                                                           
Во всех программистских проектах, в которых я так или иначе участвовал, 
ТЗ всегда писали сами исполнители. 
Так называемый нулевой этап - написание и согласование ТЗ.                                    

Алексей Хрылин  
Именно. А "серьезная система" это когда "в этом случае открутить винтиль на трубе Б..."? 

Farit  
Серьезная система - это когда самолет летать должен. Или ГПА среднее время выдерживать.                                                     
Кстати, вспомнилось: и там тоже написание и согласование ТЗ - отдельный этап.                                                        

al_mt    
На самом деле Ник прав, в том смысле, что заказчик далеко не всегда способен даже просто 
сформулировать, чего он хочет
У нас ситуация несколько другая: менеджеры прекрасно представляют в мозгу картинку что нужно, 
но не всегда способны донести до программистов. 
Точнее почти никогда
Отсюда итерационный подход. Получаем ТЗ, формулируем задачу чётко, 
рисуем диаграммки - отдаём манагерам, если возражений нет, то строим макет, 
показываем манагерам, если возражений нет, делаем "окончательную" реализацию.                                            
                                                                                                  
Но в вышеприведённом пример, на такие итерации времени не было!

Чибрикин Илья   
Есть даже специальный стиль софтверного творчества когда декларируется отсутствие ТЗ. 
ЗАбыл как кличется но идея ровно в том,   
что реализуется только мгновенное сиюминутное хотение заказчика        

Nick Sakva     
Farit писал:                                       
Рассматривался как раз-таки не быстрый, а сверхбыстрый проект.      

Для "сверхбыстрого" проекта время создания четкого ТЗ заведомо превышает время 
"сверхбыстрой реализации".                             
                                                                                                  
Farit писал:                                       
Ну, я кажется понял, что говорю в основном с программистами         
                                                                                                  
Однако! Лучше поздно, чем никогда. 
Исходное сообщение касалось сугубо программистских проблем. 
Все сообщения - тоже. Упоминаемые стандарты - программистские (по поводу ГОСТ 34, 
который "не совсем программистский", а "АСУ", высказан скептицизм типа 
что это не совсем то, о чем идет речь)...              
                                                                                                  
Цитата:                                                             
Во всех программистских проектах, в которых я так или иначе участвовал, 
ТЗ всегда писали сами исполнители...                    
                                                                                                  
Во-во!                                                                 

bigBUG       
А такую позицию как "постановщик задачи" уже отменили?                   

al_mt   
2Sakva                                                                  
Об этом очень легко судить по "времени отклика" менеджера. 
Т.е. нет такого, что програмисты отослали свой вариант ТЗ, манагеры его недельку  
(ну дня три) пообсуждали и вернули резюме. 
Нет, реакция менеджеров обычно моментальная.                                                     

impetus             
Михаил Ермак писал:                                 
1. Российская специфика будет оставаться такой ровно до тех пор, пока вы ее будете поддерживать.                                 
2. Задача изложенная в теме не требует постиндустриальных техник. 
Это задача давно решена и решение запатентовано и используется.                                                        
                             .                                                                    
"так какой длины должен быть мост?"                                     
подходим с другой стороны: российская специфика для переделывания в жалкое подобие американской 
потребует колоссальных затрат (в т.ч. интеллектуальных, эмоциональных, волевых.. 
И так переход  1991------>200х сколько народу поубивали, спилось, поуезжало)            
                                                                                                  
Задача в индустриальном изложении - и вашем индустриальном решении - будет дольше, 
сильно дороже, и скорее всего в итоговом виде - заказчику не нужна.                                                                
Потому что. Заказчик - он тоже с "российской спецификой"                 
                                                                                                  
и, блин да, МНОГИЕ аспекты российской специфики мы, живущие здесь активно поддерживаем.                                                    
например менторский тон тут наблюдаю почему-то лишь из-за границы.       
Здесь таких посылают на#%^й и они идут.                                  
                                                                                                  
Nick Sakva писал:                                   
А за разглашение в рабочее время таких вот "тайн мироздания".... шеф в отъезде, 
а секретарша на обеде!!!              
                                                                                                  
Ник, думается Вы - считаете мир таковым, и он вам платит тем же.         
                                                                                                  
бывает наоборот - чудеса случаются легко и изящно...                     
что там про крошку енота?                                                

Nick Sakva 
Благосклонность Мира по-крупному компенсируется его придирчивостью по мелочам. 
Но в данном случае усе было учтено, предвосхищено и находилось под контролем.                                                           
                                                                                                  
Перед уходом секретарши на обед, я произнес на всякий случай надлежащие заклинания 
(типа "приятного аппетита, ешьте побыстрее, а то как же мы тут и без вас и и без начальства"). 
Так что в итоге и секретарша и печать явились как раз вовремя. 

Гришнов   
порядок можно установить только на маленькой и бедной земле, а на великой и обильной - вряд ли.                                            

Т.е. те, кто несёт нам порядок - ... ну сами понимаете, чего они хотят   
                         Smile                                                                    
Vasilisk  
Вот именно. И поступать с ними следует как с супостатами 

Комплекс стандартов на автоматизированные системы АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ. ГОСТ 34.601-90 Дата введения с 01.01.1992г. Настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных видах деятельности (исследование, проектирование, управление и т.п.), включая их сочетания, создаваемые в организациях, объединениях и на предприятиях (далее - организациях). Стандарт устанавливает стадии и этапы создания АС. В приложении 1 приведено содержание работ на каждом этапе. 1. ОБЩИЕ ПОЛОЖЕНИЯ 1.1. Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединённых в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям. 1.2. Стадии и этапы создания АС выделяются как части процесса создания по соображениям рационального планирования и организации работ, заканчивающихся заданным результатом. 1.3. Работы по развитию АС осуществляют по стадиям и этапам, применяемым для создания АС. 1.4. Состав и правила выполнения работ на установленных настоящим стандартом стадиях и этапах определяют в соответствующей документации организаций, участвующих в создании конкретных видов АС. Перечень организаций, участвующих в работах по созданию АС, приведён в приложении 2. 2. СТАДИИ И ЭТАПЫ СОЗДАНИЯ АС 2.1. Стадии и этапы создания АС в общем случае приведены в таблице. +-------------------------------------------------------------------------+ | Стадии | Этапы работ | |--------------------------+----------------------------------------------| | 1. Формирование | 1.1. Обследование объекта и обоснование | | требований к АС | необходимости создания АС. | | | | | | 1.2. Формирование требований пользователя к | | | АС. | | | | | | 1.3. Оформление отчёта о выполненной работе | | | и заявки на разработку АС | | | (тактико-технического задания) | |--------------------------+----------------------------------------------| | 2. Разработка концепции | 2.1. Изучение объекта. | | АС. | | | | 2.2. Проведение необходимых | | | научно-исследовательских работ. | | | | | | 2.3. Разработка вариантов концепции АС, | | | удовлетворяющего требованиям пользователя. | | | | | | 2.4. Оформление отчёта о выполненной работе. | |--------------------------+----------------------------------------------| | 3. Техническое задание. | Разработка и утверждение технического | | | задания на создание АС. | |--------------------------+----------------------------------------------| | 4. Эскизный проект. | 4.1. Разработка предварительных проектных | | | решений по системе и её частям. | | | | | | 4.2. Разработка документации на АС и её | | | части. | |--------------------------+----------------------------------------------| | 5. Технический проект. | 5.1. Разработка проектных решений по системе | | | и её частям. | | | | | | 5.2. Разработка документации на АС и её | | | части. | | | | | | 5.3. Разработка и оформление документации на | | | поставку изделий для комплектования АС и | | | (или) технических требований (технических | | | заданий) на их разработку. | | | | | | 5.4. Разработка заданий на проектирование в | | | смежных частях проекта объекта | | | автоматизации. | |--------------------------+----------------------------------------------| | 6. Рабочая документация. | 6.1. Разработка рабочей документации на | | | систему и её части. | | | | | | 6.2. Разработка или адаптация программ. | |--------------------------+----------------------------------------------| | 7. Ввод в действие. | 7.1. Подготовка объекта автоматизации к | | | вводу АС в действие. | | | | | | 7.2. Подготовка персонала. | | | | | | 7.3. Комплектация АС поставляемыми изделиями | | | (программными и техническими средствами, | | | программно-техническими комплексами, | | | информационными изделиями). | | | | | | 7.4. Строительно-монтажные работы. | | | | | | 7.5. Пусконаладочные работы. | | | | | | 7.6. Проведение предварительных испытаний. | | | | | | 7.7. Проведение опытной эксплуатации. | | | | | | 7.8. Проведение приёмочных испытаний. | |--------------------------+----------------------------------------------| | 8. Сопровождение АС | 8.1. Выполнение работ в соответствии с | | | гарантийными обязательствами. | | | | | | 8.2. Послегарантийное обслуживание. | +-------------------------------------------------------------------------+ 2.2. Стадии этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании на основе настоящего стандарта. Допускается исключить стадию "Эскизный проект" и отдельные этапы работ на всех стадиях, объединять стадии "Технический проект" и "Рабочая документация" в одну стадию "Технорабочий проект". В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ. ------------------------------------------------------------------------------------- ПРИЛОЖЕНИЕ 1 (справочное) СОДЕРЖАНИЕ РАБОТ 1. На этапе 1.1. "Обследование объекта и обоснование необходимости создания в АС" общем случае проводят: * а) сбор данных об объекте автоматизации и осуществляемых видах деятельности; * б) оценку качества функционирования объекта и осуществляемых видах деятельности, выявление проблем, решение которых возможно средствами автоматизации; * в) оценку (технико-экономической, социальной и т.д.) целесообразности создания АС. 2. На этапе 1.2. "Формирование требований пользователя к АС" проводят: * а) подготовку исходных данных для формирования требований АС (характеристика объекта автоматизации, описание требований к системе, ограничения допустимых затрат на разработку, ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия создания и функционирования системы); * б) формулировку и оформление требований пользователя к АС. 3. На этапе 1.3. "Оформление отчёта о выполненной работе и заявки на разработку АС (технико-технического задания)" проводят оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС (тактико-технического задания) или другого заменяющего её документа с аналогичным содержанием. 4. На этапах 2.1. "Изучение объекта" и 2.2. "Проведение научно-исследовательских работ" организация-разработчик проводит детальное изучение объекта автоматизации и необходимые научно-исследовательские работы (НИР), связанные с поиском путей и оценкой возможности реализации требований пользователя, оформляют и утверждают отчёты о НИР. 5. На этапе 2.3. "Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя" в общем случае, проводят разработку альтернативных вариантов концепции создаваемой АС и планов их реализации; оценку необходимых ресурсов на их реализацию и обеспечение функционирования; оценку преимуществ и недостатков каждого варианта; определение порядка оценки качества и условий приёмки системы; оценку эффектов, получаемых от системы. 6. На этапе 2.4. "Оформление отчёта о выполненной работе" подготавливают и оформляют отчет, содержащий описание выполненных работ на стадии описания и обоснования предлагаемого варианта концепции системы. 7. На этапе 3.1. "Разработка и утверждение технического задания на создание АС" проводят разработку, оформление, согласование и утверждение технического задания на АС и, при необходимости, технических заданий на части АС. 8. На этапе 4.1. "Разработка предварительных проектных решений по системе и её частям" определяются: функции АС; функции подсистем, их цели и эффекты; состав комплексов задач и отдельных задач; концепция информационной базы, её укрупнённая структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры основных программных средств. 9. На этапе 5.1. "Разработка проектных решений по системе и её частям" обеспечивает разработку общих решений по системе и её частям, функционально-алгоритмической структуре системы, по функциям персонала и организационной структуре, по структуре технических средств, по алгоритмам решения задач и применяемым языкам, по организации и ведению информационной базы, системе классификации и кодирования информации, по программному обеспечению. 10. На этапах 4.2. и 5.2. "Разработка документации на АС и её части" проводят разработку, оформление, согласование и утверждение документации в объёме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС. Виды документов - по ГОСТ 34.201-89. 11. На этапе 5.3. "Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку" проводят: подготовку и оформление документации на поставку изделий для комплектования АС; определение технических требований и составление ТЗ на разработку изделий, не изготовляемых серийно. 12. На этапе 5.4 "Разработка заданий на проектирование в смежных частях проекта объекта автоматизации" осуществляют разработку, оформление, согласование и утверждение заданий на проектирование в смежных частях проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АС. 13. На этапе 6.1 "Разработка рабочей документации на систему и её части" осуществляют разработку рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и её эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, её оформление, согласование и утверждение. Виды документов по ГОСТ 34.201-89. 14. На этапе 6.2 "Разработка или адаптация программ" проводят разработку программ и программных средств системы, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку программной документации в соответствии с ГОСТ 19.101. 15. На этапе 7.1 "Подготовка объекта автоматизации к вводу АС в действие" проводят работы по организационной подготовке объекта автоматизации к вводу АС в действие, в том числе: * реализацию проектных решений по организационной структуре АС; * обеспечение подразделений объекта управления инструктивно-методическими материалами; * внедрение классификаторов информации. 16. На этапе 7.2 "Подготовка персонала" проводят обучение персонала и проверку его способности обеспечить функционирование АС. 17. На этапе 7.3 "Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)" обеспечивают получение комплектующих изделий серийного и единичного производства, материалов и монтажных изделий, проводят входной контроль их качества. 18. На этапе 7.4 "Строительно-монтажные работы" проводят: * выполнение работ по строительству специализированных зданий (помещений) для размещения технических средств и персонала АС; * сооружение кабельных каналов; * выполнение работ по монтажу технических средств и линий связи; * испытание смонтированных технических средств; * сдачу технических средств для проведения пусконаладочных работ. 19. На этапе 7.5 "Пусконаладочные работы" проводят: * автономную наладку технических и программных средств, * загрузку информации в базу данных и проверку системы её ведения; * комплексную наладку всех средств системы. 20. На этапе 7.6 "Проведение предварительных испытаний" осуществляют: * а) испытания АС на работоспособность и соответствие техническому заданию в соответствии с программой и методикой предварительных испытаний; * б) устранение неисправностей и внесение изменений в документацию на АС, в том числе эксплуатационную в соответствии с протоколом испытаний; * в) оформление акта о приёмке АС в опытную эксплуатацию. 21. На этапе 7.7 "Проведение опытной эксплуатации" проводят: * опытную эксплуатацию АС; * анализ результатов опытной эксплуатации АС; * доработку (при необходимости) программного обеспечения АС; * дополнительную наладку (при необходимости) технических средств АС; * оформление акта о завершении опытной эксплуатации. 22. На этапе 7.8 "Проведение приёмочных испытаний" проводят: * а) испытания на соответствие техническому заданию в соответствии с программой и методикой приёмочных испытаний; * б) анализ результатов испытания АС и устранение недостатков, выявленных при испытаниях; * в) оформление акта о приёмке АС в постоянную эксплуатацию. 23. На этапе 8.1 "Выполнение работ в соответствии с гарантийными обязательствами" осуществляются работы по устранению недостатков, выявленных при эксплуатации АС в течении установленных гарантийных сроков, внесению необходимых изменений в документацию по АС. 24. На этапе 8.2 "Послегарантийное обслуживание" осуществляют работы по: * а) анализу функционирования системы; * б) выявлению отклонений фактических эксплуатационных характеристик АС от проектных значений; * в) установлению причин этих отклонений; * г) устранению выявленных недостатков и обеспечению стабильности эксплуатационных характеристик АС; * д) внесению необходимых изменений в документацию на АС. ------------------------------------------------------------------------------------ ПРИЛОЖЕНИЕ 2 (справочное) ПЕРЕЧЕНЬ ОРГАНИЗАЦИЙ, УЧАСТВУЮЩИХ В РАБОТАХ ПО СОЗДАНИЮ АС. 1. Организация-заказчик (пользователь), для которой создаются АС и которая обеспечивает финансирование, приемку работ и эксплуатацию АС, а также выполнение отдельных работ по созданию АС. 2. Организация-разработчик, которая осуществляет работы по созданию АС, представляет заказчику совокупность научно-технических услуг на разных стадиях и этапах создания, а также разрабатывает и поставляет различные программные и технические средства АС. 3. Организация-поставщик, которая изготавливает и поставляет программные и технические средства по заказу разработчика или заказчика. 4. Организация-генпроектировщик объекта автоматизации. 5. Организации-проектировщики различных частей проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АС. 6. Организации строительные, монтажные, наладочные и другие. Примечания: * а) в зависимости от условий создания АС возможны различные совмещения функций заказчика, разработчика, поставщика и других организаций, участвующих в работах по созданию АС; * б) стадии и этапы выполняемых ими работ по созданию АС определяются на основании настоящего стандарта. MixMax - настоящий мужской клуб Стиль / Здоровье / Интернет / Техника / Оружие "Русские управленцы могут творить чудеса" Книга кандидата экономических наук, доцента ЯрГУ Александра Прохорова "Русская модель управления" (издательство журнала "Эксперт") признана национальным бестселлером. "Русская модель управления" - лауреат премии "Лучшие книги 2002 года", учрежденной Российской государственной библиотекой и Русским биографическим институтом. Корреспондент "Северного края" решил из первых рук узнать секрет "русского управленческого чуда". - Александр Петрович, так умеют ли русские управлять? - Общественное мнение наделяет нашу модель управления взаимоисключающими, казалось бы, качествами. С одной стороны, все знают, что она неэффективна, не нацелена на экономию ресурсов, что сплошь и рядом управленческие решения ошибочны, что любую работу у нас можно было бы сделать быстрее и с меньшими затратами. С другой стороны, русские как должное принимают успехи своей системы управления (в любой сфере - освоение космоса, победы в войнах, подъем культуры и искусства, проведение преобразований в кратчайшие сроки). Причем успех достигался вопреки крайне неблагоприятным обстоятельствам. На вопрос о том, хороша или плоха русская модель управления, уже ответила история. В ходе жестокого "естественного отбора" страны и народы, имеющие "слабую" систему управления, перестали существовать или же были вытеснены своими соседями на небольшие территории. Про Россию, занимающую 1/8 часть земной суши, это сказать нельзя. Значит, система управления у нас в целом успешная. - По мнению научного редактора "Эксперта" Александра Привалова, вы смогли показать органическую цельность отечественной истории. Какова же главная особенность русской модели управления? - Это "маятниковый" характер ее работы. В каждый момент времени наша система управления находится или в состоянии стабильном, застойном, или же в нестабильном, кризисном, аварийно-мобилизационном. В спокойном режиме управление осуществляется бюрократическими методами, глушится любая инициатива, навязываются шаблонные схемы работы, люди и организации заняты только собственным благополучием, система деградирует и теряет результативность. Такие спокойные времена были, например, при Брежневе, при Николае I, при Александре III и Николае II. С переходом в нестабильный режим (например, при Иване Грозном и Петре I, при большевиках) стиль действий всех управленческих звеньев меняется. Ускоряются структурные реформы, ожесточаются наказания, система становится агрессивно-конкурентной. В России при нестабильном режиме управления офицера, часть которого не могла взять высоту, могут просто отдать под трибунал и расстрелять. Такой подход, как полагают в нашей стране, обеспечивает высокие темпы отбора способных управленцев. - Это никак не похоже на конкуренцию в западном понимании... - Западное общество основано на конкурентной борьбе независимых субъектов. Государство административным путем устанавливает "правила игры" между соперничающими между собой и внутри себя фирмами, партиями, церквями, научными и художественными течениями. То есть западные модели управления занимаются как бы "администрированием конкурентов". Внутри этих ячеек тоже господствует конкуренция (за финансирование, за зарплату и продвижение по службе) между подразделениями и между работни-ками. А вот русская модель управления в своем нестабильном состоянии навязывает низовым ячейкам "конкуренцию администраторов". В России внутри каждой базовой управленческой единицы - в цехе, в команде, в фирме, в воинской части, отношения преимущественно неконкурентные. А между собой эти ячейки связываются уже конкурентными отношениями, причем за выполнение навязанной сверху задачи головой отвечает администратор - руководитель ячейки. Данный вид соперничества жестче, чем западная конкуренция, позволяя наиболее полно использовать имеющиеся ресурсы. Это делается за счет их мобилизации и перераспределения на ключевые направления, создания централизованных контрольных структур и автономности низовых подразделений. Так, например, была организована эвакуация советской промышленности на восток в 1941 году. - Как русским управленцам удаются подобные чудеса? - Оказавшись в кризисной ситуации, низовые ячейки мобилизуют внутренние ресурсы и резко повышают эффективность своей работы. Люди поступают инициативно и нешаблонно, чтобы выполнить поставленную сверху жесткую задачу. Поэтому директор советского завода орет на начальника цеха: "Мне наплевать, как ты выполнишь план! Работай хошь днем, хошь ночью, шабашников нанимай - но чтоб к концу месяца план был!" Поскольку русская модель управления формировалась фактически в военных условиях, то она работает результативно лишь в том случае, если лютость собственного начальства становится сопоставима с жестокостью внешнего врага. То есть начальство, чтобы добиться значимого результата, должно прибегнуть к такому размаху репрессий по отношению к собственным подчиненным, к какому прибегали бы внешние захватчики. Система реагирует только на лютого врага, и пока начальник таковым не станет, не заработает. Процесс управления в русской модели представляет собой противоборство между начальством и низовыми ячейками. При любых контактах между представителями власти и населения в людях просыпается стереотип низовой солидарности - они совершенно бескорыстно помогают друг другу обманывать государство, не выдают нарушителей. А государство занято мобилизацией и перераспределением ресурсов между низовыми социальными ячейками. Так сложилось исторически. Древнерусский князь забрать прибавочный продукт мог только явившись "полюдьем", всей дружиной. Эта система диктовала необходимость централизации управления армией и госаппаратом. Но текущее, ежедневное управление князь оставлял родовым и племенным структурам, впоследствии - общине или артели. "Дань давай, а в остальном - живите, как раньше". Так и жили люди в общине, затем колхозе и бригаде, связанные круговой порукой. - Влияет ли "маятниковая" система управления на русскую психологию? - Все русские от грузчика до президента держат в голове два варианта поведения. Русский - это тот, кто может в одну эпоху быть Стахановым или Корчагиным, а в другую эпоху - Чичиковым или бомжом. Эта система сложилась еще на селе, когда летом крестьяне интенсивно работают, а потом всю долгую зиму отдыхают. Лучшей иллюстрацией гибкости русского национального характера служит жизненный путь Бориса Ельцина, который первую половину жизни преуспевал в застойной бюрократической системе, а вторую половину успешно ту же систему разрушал. - Выходит, что ельцинские реформы - историческая необходимость? - При стабильном состоянии реформы невозможны. В России бунты, революции и приравненные к ним по разрушительной силе реформы являются механизмом принудительной смены спокойного состояния системы управления на нестабильное. Стране предстоит пережить мобилизации и репрессии, грандиозные достижения и жертвы. Но историки заметили, что каждый из периодов "конкуренции администраторов" характеризуется падением уровня жизни населения. Главную роль тут играют группы населения, которые опо-средуют мобилизацию и перераспределение ресурсов. В разные периоды истории - чиновники, комиссары, бандиты. - Кто является "катализатором" перехода к аварийной фазе? - Это представители параллельных властных органов, с незапамятных времен находившиеся рядом с управленцами и контролировавшие их работу. Рядом с думными дьяками - думские бояре, рядом с воеводами - фискалы, рядом с красными командирами - комиссары, рядом с директорами - секретари парткомов, рядом с губернаторами - представители президента и федеральные инспектора... Параллельные управленческие структуры должны, при необходимости, переводить систему управления из стабильного в нестабильное состояние, а в спокойное время - поддерживать готовность управленческих механизмов для такого перехода в будущем. Они наделены обширными правами по использованию ресурсов подконтрольных им предприятий и организаций, причем эти права не уравновешены соответствующими обязанностями. Такой дисбаланс дает параллельным структурам возможность смело рисковать чужими ресурсами для достижения поставленных "сверху" целей. Типичным примером может служить развертывание параллельными структурами (в лице парткомов и комитетов комсомола) стахановского движения. - Что же останавливает мобилизационный маховик? - Постепенно между системой и людьми достигается компромисс - система делает вид, что требует реализации непомерных требований, а исполнители делают вид, что демонстрируют энтузиазм, хотя на самом деле большую часть своих обязанностей они уже игнорируют, выполняя только внешний ритуал. В стабильное время бюрократия в силу своей неэффективности и корысти не позволяет сожрать свой народ ради достижения каких-то амбициозных государственных целей. А на низовом уровне включается защитный механизм, способный оттянуть момент наступления нестабильного состояния - уравниловка. Застой при всем убожестве обеспечивает относительно благополучное состояние людей и рост численности населения. Для навязывания аварийного стереотипа нужны нарушители общественного спокойствия, карьеристы и мироеды, энтузиасты перемен. Люди интуитивно понимают, что любой человек, много заработавший в бригаде, представляет угрозу окружающим. И когда рабочие в курилке бьют "передовика", они защищают себя и свои семьи, а заодно губят отечественную промышленность. - Значит, конкуренция внутри коллектива в России нехарактерна? - Главный фронт борьбы у нас проходит не между отдельными работниками, а между бюро, бригадами, отделами и лабораториями одного предприятия. В русской конкуренции, как в старинной народной забаве, дерутся не "один на один", а "стенка на стенку". Руководитель проиграет, если поссорит всех со всеми, столкнув подчиненных лбами. "Единоличная" конкуренция невыгодна и персоналу, и фирме в целом, так как разрушает единство групповых интересов и отвлекает от главного - от конкуренции с другими подразделениями. В России пять человек, не конкурирующие друг с другом и все вместе соперничающие с соседним отделом, сделают больше работы, чем пять человек, конкурирующие только друг с другом и больше ни с кем. Отсюда практический вывод: если у вас шестеро подчиненных и вы хотите развязать между ними конкурентную борьбу, то вам следует объединить их в два бюро по три человека в каждом и так распределить права и обязанности, чтобы в каждом из бюро личные интересы были едины, а интересы двух бюро как подразделений - противопо-ложны. - Александр Петрович, есть ли перспектива у русской модели управления в эпоху глобализации? - Она будет развиваться при сохранении основных особенностей. Правда, ключевой ролью государства придется пожертвовать, так как ведущие управленческие функции придется выполнять низовым единицам - предприятиям. Российская экономика станет конкурентоспособной лишь в том случае, когда продавцы будут сражаться за покупателя с не меньшим рвением, чем их деды бросались в бой "За Родину, за Сталина!", когда менеджеры не будут согласны даже на второе почетное место в общенациональном рейтинге предприятий, когда сбытовики станут добивать конкурента демпингом с тем же энтузиазмом, с каким их прадеды раскулачивали ни в чем не повинных односельчан... Время покажет, способно ли наше общественное сознание на такие метаморфозы. Беседовал Сергей КУЛАКОВ. Северный край (Ярославль). 08.07.2000. См. также