<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Вроде, одна статья не противоречит другой. В той (которая как бы опровергается) говорится о том, что для внедрения нужны 3 ключевые роли: руководитель проекта, программист и специалисты по текущим процессам. А в этой, насколько я понимаю, просто подразумевается, что все эти роли должны сочетаться в одном человеке, но все равно нужны все. То есть отличие не принципиальное.
А насчет инструкций — да, пользователи, которые уповают только на них и не желают думать сами, — унылое зрелище. Все возможные ситуации в инструкцию не напишешь, да оно и не надо.
На самом деле автор описал текущую ситуацию, что около 80% руководителей проектов сейчас это люди с минимум опыта или программиста или консультанта, под минимумом подразумеваю около 1-3-х лет работы и обладающего самыми минимальными знаниями в предметной среде. Почему то считается что руководитель проекта это на 90% менеджер и только чуть чуть программист или консультант в какой то сфере. Однако мы забываем что внедрение (именно проектное, крупное) — это прежде всего работа, связанная с использованием качественного портфеля знаний и с учетом российский реалий знаний в нескольких предметных областях. Как мне видится успешность проекта это прежде всего ключевое понимание роли, задач подрядчика и заказчика в проекте и именно на руководителя проекта ложится понимание общей концепции проекта. А с таким багажом знаний как у большинства поэтому и случается так что большая часть проектов движется со скрипом и постоянными срачками. За сравнением далеко ходить не надо, как думаете может руководить аудиторской проверкой человек обладающий знаниями ниже чем рядовые аудиторы, будь он хоть супер менеджером? нет, так и в любой сфере консалтинга. А в 1С пожалуйста.
Вроде, одна статья не противоречит другой.
Противоречит. Цитирую оппонента: «пойдет любой человек с организаторскими компетенциями который сможет выполнить остальные 3 пункта.»
Как раз организаторов, способных устраиваить «еженедельные совещания», предостаточно, профессионалов не хватает.
Не удержусь от повторения своего же комментария к статье «4 ключевые…»
Если руководитель посчитает, что ему требуется реинжиниринг, тогда он обратится в реинжиниронговую фирму, и там с него сдерут немерянное бабло за консультации и столь же немерянное на покупку автоматизированной системы «To be» (как правило, эти фирмы знают, что «надо» внедрять, еще не знакомясь с заказчиком). Затем сумма возрастет еще в два-три раза за внедрение. Начнется текучка кадров. И долгий процесс восстановления разрушенного управления/учета.
ИначеЕсли руководитель осознает, что автоматизация хаоса прводит к автоматизированному хаосу, он найдет и возьмет себе в штат квалифицированного автоматизатора, с помощью которого предотвратит развод фирмы на бабки и наведет порядок в своих бизнес-процессах таким способом, что «левых» внедренцев приглашать не придется. ИМХО (в смысле, КонецЕсли)
Может ли проект, возглавляемый менеджером, быть успешным?
Может в двух случаях
1) Менеджер ничего не понимает в информатике и полностью полагается на ведущего программиста.
2) Ведущий программист имеет право вето на любые идеи руководителя проекта, который якобы что-то в информатике понимает.
Конечно, оба варианта не гарантируют успеха. В любом случае ведущий программист проекта должен быть упомянутым квалифицированным автоматизатором, а не «крутым кодером».
ОФФ. На заре моей автоматизаторской деятельности нас обязали еженедельно планировать и учитывать рабочее время. И старый мудрый начлаб посоветовал мне отводить 60-80 процентов времени на ликвидацию последствий вмешательства высокого начальства — в современной терминологии, руководителя проекта.
Прилагаю аватарку для статьи 🙂
Может ли проект, возглавляемый менеджером, быть успешным?
Еще не факт, что в описанной ситуации ведущий программист захочет брать на себя
обязанности руководителя проекта и тащить на себе целую гирлянду спиногрызов.
Так что ТОЛЬКО увеличение стоимости проекта — это в лучшем случае.
У кого-нибудь есть примеры проектов, в которых РП не «из программистов»?
Мне пока не ясно — актуален ли данный «разбор полетов»?
(6)
Судя по количеству плюсов, которые получила статья ,
таких примеров предостаточно.
Я так понимаю, что каждый проголосовавший согласен с доводами автора этой статьи.
(7) Не так. Я тоже поставил плюс за ту статью, однако как рекомендацию к прочтению/размышлению, а не как согласие с содержанием. Мне ближе позиция этой статьи, и именно в том плане, что хороший программист — это уже руководитель, поскольку постоянно принимает решения в условиях неопределенности, а также способен к абстракции — увидеть сущность объекта/процесса (в статье упоминается ООП в широком смысле) под наслоением малозначимой атрибутики. Нужно только научиться организовать работу команды («надо работать»).
(6) Я сам с командой делал проект большой и успешный. Но там руководитель проекта только орал при задержке этапов и выбивал/предоставлял ресурсы. Т.е. как в 1) моего 4-го поста.
(7) Мой плюс тоже и там, и там. Публикация как повод к размышлению и обсуждению часто заслуживает плюса вне зависимости от того, разделяю я мнение автора или нет.
Зэ бэст оф зэ бэст — это когда руководитель проекта + хороший программист-внедренец = хэппи енд проект.
я успел поработать в команде, где, во-первых, РП был, и был он одновременно и кодером, и постановщиком ТЗ, и аналитиком, и составителем договоров, и тестировщиком у своих подчиненных программистов, при этом эти же программисты были одновременно немного аналитиками, тестировщиками, документаторами, кодерами, внедренцами. затем я работал в команде, где эти функции были четко разделены: есть аналитики (одновременно и тестировщики), есть документаторы, есть разработчики, есть постановщики ТЗ, есть свои внедренцы, проект-менеджеры и руководитель отдела, но вот РП не было. может спор из-за терминологий?
(8)(9) Тогда нужно изменять систему голосования, иначе не понять кто за, кто против.
Статья моего оппонента не дискуссионная, это не призыв к обсуждению, это
УТВЕРЖДЕНИЕ.
«Надо еще и работать» … 😀 Надо распечатать и повесить в своем кабинете…
(12)
А комментарии как раз и нужны, что понять, кто за и против. Тем более в комментариях к той статье тоже развернулось немаленькое обсуждение.
(12)
УТВЕРЖДЕНИЕ.
Но обсуждение из 138 постов все же случилось 😉
(13) Компьютер должен работать, а человек — думать.
(6) есть, есть, мое предпоследнее место работы — БТК: крутецкий оптовик всего, что втыкается в розетку, не менее двух лет БиТ сосал бабло, УТ+Инталев, в результате одного ключевого пользователя (продажника) уволили, другой (финдир) в конце проекта писал «все проводки неправильные», прогнали битовцев, уволили всех. кого брали на подхват. начали сокращать своих штатных 1снегов, завели речи о возврате на 7.7
руководитель от БиТа «Кирилл Гусев»:mailto:kgusev@1cbit.ru
(7) пошел поставил —
+(16) форма расходного ордера на определенную выплату содержала пять (пять!) разных реквизитов, которые должен был заполнить оператор, чтобы указать системе, что это ордер именно на такого рода определенную выплату
(17) Это ты погорячился…
вывод-то в итоге какой? надо работать? ..ли…
(20) Надо. Над собой 😀
(20) Надо. В том числе надо «работать» с теми, кто мешает.
С теми, кто занимает чужое место, кто присваивает
себе кем то заработанное. Это уже отдает политикой, но без этого никак.
+512 !!!
2 All
Уважаемые коллеги, наверное, многим будет интересно прочесть книгу
Фредерика Брукса «Мифический человеко-месяц, или Как создаются программные системы»
(Frederick P. Brooks, The Mythical Man-Month).
Брукс — профессор вычислительной техники, известен, прежде всего, как «отец IBM System/360» (кто знает — поймет 🙂 ).
В США полагают, что без прочтения книги Брукса не может состояться ни один руководитель программного проекта.
—
А если взять нашу, российскую реальность, то, ес-сно, когда босс ни черта не понимает в разработке,
ориентирован только на зарабатывание «буказоидов», и при слове «ТЗ» впадает в ступор, то можно легко представить
итоговое качество и сроки проекта… 🙂
Еще раз — ОГРОМНОЕ СПАСИБО автору !!!
+ (23)
(23) (24) (25) На Инфостарте есть все
😉
(26)?
(27) Лучше уж тогда — с картинками :), вот отсюда :
(в формате PDF, 1.5Мб)
(29) У меня именно с картинками. Из юбилейного издания 95 года
(29) на либрусеке вообще-то с картинками …добавлять некогда было в архив…
(31) С картинками, да. Сейчас сижу, читаю. Спасибо за ссылку)))
из Брукса, в поддержку (0) :
«Вывод прост: если над проектом работают 200 человек, включая менеджеров, являющихся наиболее знающими и опытными программистами, увольте 175 бойцов, и пусть менеджеры снова займутся программированием.»
ок. подкину дровишек для разогрева )))
1. Любителям и фанатам IBM посвящается: Написать программу может и дурак, а вот внедрить даже хорошую программу может только эксперт ©
2. В моей статье разделяются понятия «ТЗ на программирование» и «ТЗ на внедрение программы». Это ооочень важный момент )) Ни в один из своих проектов внедрения я не допускаю программиста к коду программы (они у меня только инструкции пишут и ошибки ищут). Если без изменения ПО ну ваще никак, стартую параллельный проект, куда выношу все изменения за отдельную плату и только после того как мне обоснуют их необходимость в цифрах, т.е. если это изменение позволит улучшить какой то важный и конкретный показатель организации и получить прибыль (все пожелания аля «ну без этого ваще никак» и «ну мне так удобно» идут под запись, но за рамки проекта). В статье рассматривается внедрение программ, тема проектов по программированию выходит за рамки статьи. То что уважаемая опозиция домыслила ряд идей, это проблемы опозиции )) Не надо мне приписывать ошибочные формулировки ))
3. В моей статье идет оперирование понятиями Роли (как верно заметила Alraune (1)) К термину Роль больше подходит термин Компетенция, чем термин Должность. Хочешь совмещай компетенции (роли) в одном специалисте, хошь — дроби… все зависит от ситуации. По должности ты можешь быть хоть техничкой по поддержанию санитарных норм в туалете, а по ночам хакером уносящим тонны килобаксов из ВТБ24 ))) Сейчас у меня в работе 25 проектов, где то я в роли руководителя, где то в роли программиста, где то в роли консультанта, а где то в 3-х ролях сразу. И как быть? Что же делать? )))
4. И как верно заметил Арчибальд (8) — беда в том что не у всех хватает силы регулировать восприятие сущностей на разных уровнях абстракции. Это проблема всех молодых или заблудившихся специалистов. С возрастом и опытом, если не заблудишься, эта способность появляется. А название должности значения не имеет. Будь ты программист, руководитель проекта, отдела, зам директора, директор или президент. Назвать себя можешь как душе угодно, внутренность и сущность от этого не поменяется ))
5. И вообще я ярый противник автоматизации… объяснительная тут )))
(34)
Программист, консультант — да какая разница? Они ж ресурсы.
Вот из небрежностей (сырых дровишек) и любых РП и получается провал.
© A.Y.
Что хочется сказать… Если не впадать в крайности, то можно прочитать обе статьи более внимательно и не найти в них по-настоящему значимых противоречий, а объединив и выделив из них самое важное / полезное — получить более полную и подробную картину внедрения. Во всяком случае лично я особых поводов для противостояния не вижу…
Руководитель проекта конечно должен разбираться в программировании, понимать и представлять себе как возможно решить ту или иную задачу в конкретной системе учета. Это не может быть только менеджер, но в первой статье нигде и не говорится, что он должен быть исключительно им. При этом РП должен обладать и управленческими (организационными) навыками, и с этим тоже нельзя спорить — «обычный» программист («кодер») с этой ролью не справится. Собственно в этой основополагающей причине спора я особых расхождений не нашел: есть подозрение, что авторы говорят немного о разных вещах в одной терминологии. В первой статье всего навсего речь идет больше об «управленческой» стороне процесса… да и первая статья скорее больше инструкция по внедрению (именно как правильно организовать рабочий процесс), здесь же больше мысли о сути вещей… О деталях (вроде инструкций) конечно можно спорить.
(17) Основываясь на вышесказанном, считаю, что минус не заслужен.
Пока писал свой пост, автор в (34) сам уже подтвердил мои предположения… 🙂
del
(35) человек, дорогой, от куда ты взял эту мысль? подумай… в том что ты выделил в качестве цитаты этой мысли не было и быть не могло )
еще раз прошу не надо мусор из ваших голов приписывать к моим формулировкам.
(39)
Почитал про Растам-ИТ, больше вопрос и замечаний не имею.
(34) Ну вот, опять внедрение «TO BE». Особенно примечательно
И это при том, что отнюдь не доказано, что внедрение данной компоненты проекта (которую хотят изменить)в неизмененном виде улучшит какой-то важный показатель.
Конечно, методически это правильно: отдельно внедряем то, что у нас есть «AS IS», говоря заказчику, что это и есть для него «TO BE». А потом уже за отдельную плату подгоняем то, что внедрили, под реальные потребности бизнеса (не хотелки, а именно потребности). Это нормальная позиция аутсорсера. Хлеб его.
М же ближе другая позиция, хотя тоже двухэтапная. Реальное проектирование системы с необходимыми отклонениями/добавками от того, что есть на рынке, включая отделение потребностей от хотелок, и создание этой системы (доведение функционала до потребностей бизнеса). Менеджер-непрограммист на этом этапе, скорее, навредит, чем поможет. Второй этап, внедрение, гораздо менее интересен с позиции творчества, и тут уж в самом деле программисты нужны только на исправление ошибок.
Позволю внести свои пять копеек:
Руководитель пишущий код — плохой руководитель. Это не означает, что он не должен уметь это делать, это означает, что он находится не на своем месте. Если руководитель работает за подчиненного (а написание кода это работа за программиста) может означать только два варианта:
1. Нехватка ресурсов.
2. Ненужность руководителя.
Первый вариант должен решаться в кратчайшие сроки, а его наличие считаться форс-мажором. А второй вариант говорит сам за себя — проект тривиален и не требует столько ресурсов сколько потребляет.
(42)
…
1. Нехватка ресурсов.
2. Ненужность руководителя.
Если на проекте больше одного исполнителя, то нужен руководитель. Выделять отдельного человека на руководство не всегда целесообразно. Совместительство требуется в большинстве случаев.
(43) Это не руководитель — это координатор. Не надо теплое с мягким путать. Координатором и секретарь может быть.
(41) Арчибальд, ну не мне тебе рассказывать, что уж если выводить правила, то такие которые помогают в большинстве ситуаций.
И если внедрять 1С Бухгалтерию 8 или 1С ЗУП 8, то в большинстве ситуаций типовой функционал достаточен для запуска системы и выполнения первостепенных функций, для основных целей — экономия затрат, снижение ошибок, получение базовой информации и отчетов. Все остальное второстепенно и может ждать, потому выносится за проект.
А если говорить о всех возможных ситуациях, то можно написать целую книгу с учетом всех возможных условий и один фиг промохнешься что то упустишь т.к. в реальности правил нет, есть лишь задача и человек способный ее решить и не способный, тот человек который умеет добиться результатов я условно называю РП, в моем понимании РП это не чья то должность, а статус (навык, роль, компетенция, характеристика) человека который умеет добиваться результатов. А то как он добьется результата, зависит лишь от его уровня знаний.
Любые правила и категории выдуманы лишь человеком и зависят только от его опыта. В реальности ни одного правила не существует 🙂
Потому любые правила которые я обозначаю они нужны лишь для новичков и помогают лишь в статистическом большинстве ситуаций. Это не панацея и не закон нарушив который вас растреляют. Умеете решать задачи по другому — ваше дело. Я тоже не фанат правил, как своих так и чужих, и если вижу что в какой то ситуации правило которое помогало ранее навредит — я его убираю и действую без него или придумываю новое. Но такой подход не годится для новичков, т.к. их знания еще не достаточны для того чтобы жонглировать правилами в реальном времени… человеку который только входит в новую область знаний нужны конкретные инструкции.
И если человек которого волею судьбы поставили ответственным за сложную задачу — создать информационную систему, будет искать подсказку, то что ему поможет? Эта опозиционная отрыжка в виде попытки назвать руководителей бесполезными людьми или моя статья которая дает конкретные подсказки?
(44) Руководитель тот кто несёт ответственность за деятельность бригады, команды, группы, отдела. Если он при этом совмещает руководство с производственной деятельностью, то это руководитель по совместительству. А так получается что ты просто не признаёшь существование совместительства.
Ответственность штука сложная. На много сложнее взять на себя ответственность и выполнить обязательства любой ценой.
Гораздо проще мнить себя пупом земли, выполнять свои должностные инструкции, и дальше мониторов не заглядывать.
А управление это способность достигать результатов. Что для этого нужно? Да все!
Надо — глав.буха соблазнишь, надо — столы потаскаешь, в гостиницах без отопления поспишь, в самолетах полетаешь без передышки неделю, выслушаешь какой ты козел от 8 из 10 сотрудников, пару ночей без сна перебьешься перед закрытием проекта…
И все эти особенности как правило знают лишь те кому приходилось нюхать такое слово как ответственность, чтобы зарплату получали те кто кроме программирования в этой жизни ничего не хочет.
«Наилучший руководитель — тот, о котором люди знают только, что он существует. Когда его работа выполнена, они скажут: ‘Мы сделали это сами’». ( Лао Цзы)
(46) Более того я не только его признаю, но и описываю ситуации возникновения данного явления. Один из которых — это простота проекта, при которой исполнитель может попеременно исполнять разные роли. Половина людей на этом сайте приходя к клиенту играют роль менеджера по продажам, сев за компьютер — руководителя, технического писателя, программиста, тестировщика (роль о которой все забыли), а вернувшись к клиенту с результатами — роль внедренца. Дальше больше — они начинают играть роль тех. поддержки.
А когда мы по совместительству работаем? Ответ только один — когда экономим мы, или экономят на нас. Отсюда и мое отношение к совместительству. Это либо жадность клиента, либо жадность исполнителя (руководителя). А любая жадность — это дефицит, а почему СССР развалилось? Потому что дефицит был (не только из-за этого конечно, но и из-за этого то же). Пока проект мал (или мало проектов) — жадность работает на нас, как только проект растет (размножается) — жадность играет против нас.
Мое мнение РП требуется не тогда, когда появляется второй (третий, десятый) программист, а когда появляется команда (пусть и из двух человек) которой надо управлять (принуждать к определенным действиям, для получения результата). Однако хорошим руководителем я считаю только того, кто может встать(а не встает) на место подчиненного и выполнить за него работу, прикрывая тем самым случаи форс-мажоров.
не возьму за чужую голову, что там как, в 1с «внедрить типовуху» до сих пор называлось «сервис-инженер»
большинство присутствующих, имхо, под «проектом» имеет иное
(49)
И что ни разу на проекте не требовалось 1,5 программера и 0,5 рукля? Ой не верю! А если потребуется, то клиент будет платить за двух программистов и одного рукля. Накладненько выходит. При избытке клиентов, конечно, можно одного рукля нагрузить несколькими проектами, но так бывает не всегда.
Более того, рукль, который умеет кодить, но не кодит, со временем теряет квалификацию. Разучивается.
(51) Уж прости, но не бывает «полтора землекопа». Их либо два, либо один. Либо у проекта дефицит, либо профицит, либо проектов более одного.
(52)
Ещё более не бывает людей, умеющих программировать, но не программирующих. Твоё пожелание о том что рукль проекта должен уметь
, но только в форс-мажоре. Или форс-мажоры должны быть постоянными или квалификация такого специалиста быстро упадёт.
(53)Да тут ты прав — со временем она падает (как программиста), зато растет как руководителя и форс-мажеры случаются редко. Для себя я принял правило — не писать где руковожу и не руководить где пишу. Пока помогает. Правда, пишу все реже и чаще для себя (автоматизация средств атоматизации).
(54)
Правда, пишу все реже и чаще для себя
Это всего лишь возраст, чем бы Вы себя не утешали.
Не всем дано быть программистами до 60-ти.
Это не хорошо и не плохо, это — жизнь.
(54) У меня похожее правило, только оно называется так: приступать к выполнению конкретных задач, только если загружены все участники, в соответствии с приоритетами. Пока кто то начал уходить от приоритетов или халтурить — ищу причины, устраняю — это первостепенная обязанность если ты взял на себя ответственность за результат.
И если участники все заняты своими делами, тогда приступаю к выполнению сам, беру как правило те задачи, которые не потянуть не программистам, не консультантам. Это или конфликты или политика или улаживание противоречий между различными сторонами. Ну а когда время освобождается на старое и доброе программирование так что получается уйти в него с головой и не думать о течении проектов, ну это почти что праздник души ))
(50) ну так а ты возьми общепризнанные определения
тут
или тут более просто и красиво
+ Учти что проект проекту рознь. одно дело «внедрить» 1С БП 8 Базовую там где 1 гл.бух сидит из всей бухгалтерии. Там ей пару вводных расказал, инструкции сунул — дальше она сама. Другое дело внедрить ту же БП или ЗУП на предприятии в 500 человек, со штатом бухгалтеров (читай — пользователей) — человек 20.
Но даже эти проекты можно считать относительно простыми, если суметь удержать рамки.
А вот если взять проекты где 1000 пользователей… то там скулы трещат по швам и на пару лет приходится забыть про личную жизнь.
Сунь туда своего сервис-инженера или программистов-фанатиков (которых хлебом не корми дай попрограммировать) без компетенций по управлению и посмотри что станет с проектом.
Сервис инженер загнется после первого же конфликта сторон, проргаммист не сумеет выдержать рамок, начнет изменять программу и проект начнет растекаться как понос. К дате окончания контракта выяснится что результатов нет и система в состоянии не стояния — хотя вроде программировали днями и ночами.
и еще добавлю ) в комментах я пишу не для того чтобы убедить себя или вас )
просто у меня посещаемость на блоге подскочила, подключение людей в группы и рейтинг моей статьи начал расти. я не мог понять почему )
а потом один из программистов (один из не многих кого я уважаю) кинул мне статью на этот холиварчик и я решил подкинуть дровишек ))
а себе я уже давно все доказал (с) В.Высоцкий
1. Почему предприниматель, организатор и специалист нужны друг другу?
2. Стадии роста специалиста по ИТ
(45) А я, собственно, и не возражаю. Не бывает универсальных рецептов. И те два подхода, в 41 посте, я не противопоставлял, а сопоставлял. В реальности они вряд ли встречаются «в чистом виде». Если автоматизация начинается «с нуля», от арифмометров — первый подход должен превалировать. И совершенно другая ситуация, когда предстоит переход от ПУБ к КА. Там с большой вероятностью продуктивнее будет второй вариант.
общепризнанные = признанные мной — позиция ожидаемая.
походу ты так и не понял, что расхождение в одном пункте, но принципиальном:
РП должен уметь программировать (в данном случае — в 1с), просто потому, что он — архитектор системы
разумеется, что речь не идет о «типовых» внедрениях
**
минус в (57) — за голимую саморекламу
(60) А нужен ли архитектор при строительстве хрущоб? Там прораба достаточно.
(61) Присоединяюсь!
А нужно ли вообще строить хрущобы ?
Может, немного подумать головой и построить что-то получше — где и архитектор нужен ? 🙂
Написано разумно. Единственное, есть непонимание некоторых нюансов. Они не столь банальны, так что это простительно.
Руководитель — действительно не профессия. Это способность. И тот, кто этого не может, никогда не поймет, что означает руководить. Что значит «взять на себя ответственность». Или «организовать рабочий процесс». Я могу таких понятий накидать много, но грамотный управленец отличается тем, что видит и делает все это сразу, в комплексе, а вот тот, кто смотрит снизу, увидит только «регулярные совещания».
Нюанс — подход не становится более формальным, он становится принципиально другим. Просто Вам этого не видно. А виден результат — регулярные совещания, фиксация планов «на бумаге», «разбор полетов» и т.д. Просто у айсберга есть еще подводная часть. Программисты, которых назначили руководителями отделов, очень часто начинают именно с этих ошибок — копируют надводную часть айсберга, не зная о подводной.
Попробую перевести — программмистов, рвущихся в организаторы, предостаточно. Грамотных руководителей не хватает. Ошибка понятна — Вы описываете проблему на том уровне, на котором ее понимаете.
Напоминает старый анекдот «х…ню мы не лечим, а п….ц неизлечим». Вам ведь не надо напоминать про квалификацию врача, сказавшего эти слова? Открою секрет — нормальные, грамотные руководства пользователей — существуют. Их можно и здесь найти. Если только! — задаться вопросом «а поймут ли вас пользователи?» К сожалению, пока я вижу, что этим вопросом Вы даже не планируете задаваться.
К слову, сам я программист. Повидал и хороших и плохих руководителей. И хороших и плохих программистов. Экзистенциальная позиция автора мне тоже знакома хорошо, а ИТ среде это, к сожалению, не редкость. Впрочем, специфика профессии такова.
(61),(62)
разумеется, что речь не идет о «типовых» внедрениях
пример «эффективного менеджера» : чубайс — авария в СШ, цены на энергию
(58) К Вашему пункту 2 («Стадии роста…») :
6. Просветление. Прошедши сквозь стадии 1-5, и поняв, что более заняться нечем,
начинает блогосферную деятельность…
Sorry. «it was just business, not personal»
(63) и другие:
Что значит «взять на себя ответственность»
расшифруйте, плиз
при Сталине просто — не справился — расстреляли
потом расстрелы убрали, а «товарищи» остались
конкретно, в чем заключалась ваша ответственность как РП, во-первых, перед подчиненными, во-вторых, перед заказчиком.
конкретно — ваша, и конкретно — сколько
ну, т.е, ваши подчиненные знали, что если проект провалится, вы ответите конкретной суммой денег?
(65) «Взять ответственность» — вот тут как раз пока не «возьмешь», не поймешь 😀 И обьяснить невозможно.
Те, кто реально руководит, организует, а не сидит на должности, поймут. И еще те, кто занялся своим бизнесом. Остальным могу сказать только — попробуйте.
Вот описать типичные проблемы при этом — это пожалуйста — кто-то не знает «как делать», кто-то не знает «что делать», в смысле куда двигаться. В результате как раз и мало людей, способных это сделать.
Что еще хотелось бы добавить по поводу статьи — из собственного опыта — профессиональный управленец всегда найдет взаимопонимание с профессиональным программистом, чего, к сожалению, не скажешь наоборот. Наш брат даже с себе подобными иногда не может найти общего языка 😀
(67) «И обьяснить невозможно.» vs «профессиональный управленец всегда найдет взаимопонимание с профессиональным программистом, чего, к сожалению, не скажешь наоборот»
ну, я так понял, что ответственность ваша носит некий нематериальный характер.
собственно, это и есть и причина развала союза, и провалов 1сных проектов
(60) Архитектор и руководитель — это разные роли. Одна роль отвечает на вопрос: «Как может быть?», а вторая: «Как это будет достигнуто?». В одном человеке роли совпадают до тех пор, пока проект мал (или мало проектов).
(69) стройка. есть архитектор (Как может быть). есть прораб (Как это будет достигнуто). Вы не путаете производителя работ с руководителем проекта?
Королев — что бы сделал, не будь инженером?
И еще раз — чубас — …
Вы не должны спасать весь мир, только свой небольшой кусочек и еще чуть-чуть, если сможете!
© Alan Carter The Programmers’ Stone (Программистский камень)
(67) «И обьяснить невозможно.» vs»профессиональный управленец всегда найдет взаимопонимание с профессиональным программистом, чего, к сожалению, не скажешь наоборот»
Все правильно, я программист, а не управленец, в чем сразу и признался 😀 Просто я понимаю, в чем разница, а вот обьяснить Вам, что значит «управлять»… Образно говоря, Вы просите меня обьяснить Вам «как научиться плавать» или даже «что значит плавать», а обьяснить это нельзя в принципе, понять это можно лишь начав плавать. И то, научиться этому — это одно, а получать от этого удовольствие и сделать это частью своей жизни — совсем другое, может, Вам это и не подойдет.
собственно, это и есть и причина развала союза, и провалов 1сных проектов
А я еще про комитет 300 слышал, и про зеленых человечков 😀
Если серьезно, то не торопитесь обобщать, прилив позитивных эмоций людям Вы, конечно, обеспечите, весь вопрос — а что это даст Вам?
Я, может быть, не очень четко указал центральный посыл своей идеи — я, в противоположность автору статьи, считаю, что руководитель проекта не обязательно должен быть хорошим программистом, а вот хорошим руководителем он должен быть обязательно. Обосную — грамотный руководитель может плохих исполнителей и поменять, а вот при плохом руководителе и хорошие сотрудники могут каши не сварить. Подчеркну — «может» не значит «будет». Просто шанс успешного доведения проекта на порядок выше.
Сразу могу ответить на первое возражение: «а как он разберется, где хороший программист, а где нет?». Ответ: сам — никак. Но на моей памяти хорошие управленцы всегда имеют множество хороших знакомых специалистов в самых разных областях, и в том числе в ИТ сфере, способных верно оценить потенциал сотрудника. И не припомню ни одного случая, когда бы хороший управленец принял на работу плохого программиста. Больше того, куча примеров, когда толковый начальник ИТ отдела вообще в 1С не шарил ну просто никак, при этом никаких проблем в этой сфере не было, все решалось очень быстро и эффективно.
(70) Давайте подытожим роли:
1. Заказчик (Сколько денег?)
2. Руководитель проекта (Как работать?)
3. Архитектор (Что делать, не вдаваясь в детали?)
4. Ведущие программисты (инженеры по оборудованию) (Как реализовать детали? На чем будет работать?)
5. Тестировщики (Работает?)
6. Тех. писатели (Как помочь?)
7. Внедренцы (Как обучить пользователя?)
8. Тех. поддержка (Как обеспечить гарантию (бесперебойную работу)?)
Я забыл наверняка что-нибудь — подправьте если не сложно.
(73) 1. Заказчик — ЧТО (в первую очередь!) / Зачем (цель проекта) / Когда (сроки) / Почём…
2. Руководитель проекта — Что / Зачем (цель проекта) / Кто (коллектив) / Когда / Почём
3. Архитектор — Что (вдаваясь в детали!) / Зачем / Когда / На чём
© Alan Carter The Programmers’ Stone (Программистский камень)
Первая из обсуждаемых статей относится как раз к «формальным структурам». Это дает автору право на фразу «Ключевая проблема в том что внедрением занимаются программисты. Хотя это задача управленческая.» Другими словами, программист без управленческих навыков завалит проект (хотя программистов без управленческих навыков не бывает, но навыки могут оказаться недостаточными).
Вторая статья (эта) касается проблем, «которые программисты считают наиболее важными». В основном — проблема постановки задачи, которой просто не существует при типовых внедрениях. Там задача поставлена изначально и корректировке не подлежит. А тут речь идет о том, что из менеджеров (как правило) постановщики задач никакие, а программист (не кодер, конечно, а втоматизатор) — это прирожденный постановщик задач. Кстати, за пивом это обсуждают программисты, которых по объективным или субъективным причинам к постановке задач не подпускают.
Статьи, таким образом, относятся просто к разным сферам деятельности. Первая — как организовать работу конвейера по сборке «Жигулей». Вторая — кто может собрать реальный автомобиль из запчастей к «Жигулям».
(72) еще одна характерная примета: «вот обьяснить Вам, что значит «управлять»»
я не просил объяснять это, я просил (риторически) сказать, в чем заключается ваша «ответственность», из-за которой ушей не видно.
(74) Заблуждаетесь. Заказчик никогда не знает что ему нужно, в какие сроки это будет сделано, какова себестоимость. Он может ответить только на вопрос сколько он готов заплатить и кому.
(75) я с шестерки двигатель снимал в одиночку. разобрал, собрал и поехал 🙂
И еще одна цитата
+(78) … кому конкретно. тендер, понимаешь
(80) Забыл в (73) роль «Менеджер по продажам (Как объяснить клиенту, что это надо делать за N$ период Т и в конторе «Рога и копыта» :))» — позор на мои седые волосы…
(78) Я, конечно понимаю смысл Вашего возражения — в контексте книжек типа «Физики шутят»… 🙂
Но ведь, по большому счету, нормальный заказчик знает — ЧТО он хочет получить (eg, систему учета «Рога и копыта»),
срок и примерную сумму, за которые он хочет это получить. А уж на сколько его попытаются развести — бог знает…
Наверное, если руководитель проекта — из программеров, то заказчику будет легче… В России, по крайней мере… 🙂
(82) Не так… Заказчик обращается к автоматизатору по двум причинам:
1. Наличие свободных средств.
2. Попытка решить ряд проблем.
В первом случае — это автоматизация ради автоматизации («Мне такую же, но с перламутровыми пуговицами»), давайте не будем рассматривать — это не проектная работа, а развод клиента на бабки (кстати полезна для клиента — аля пьявки).
Во втором случае — клиент не знает, что хочет (где у него проблема) т.к. решил бы ее сам, а не обращался на сторону.
(76)
Опять двадцать пять… Что такое «мокрое»? Пока не попробуешь, не поймешь, чем оно отличается от сухого. Попробуйте взять на себя ответственность за свою работу, за свою жизнь, за свои решения, поймете. Хотя, даже если сейчас и не поймете, с возрастом все равно придет.
(75) В точку. Именно об этом я и пытался сказать в (36). Авторы спорят о разных вещах…
Если так случилось, что руководитель проекта не программист, то все просто — он должен организовать «кофе, чай и бутерброды» программистам, а дальше все зависит от них (как всегда), смогли самоорганизоваться, выбрать из своего круга «теневого» руководителя и выполнить работу — молодцы, нет — значит, можно сказать, что руководитель не программист, не профессионал, в этом все дело, и дальше продолжать любить себя;-) Программисты всегда в выигрыше, в общем;-)
(83) По первому пункту — согласен. По второму — нет.
Клиент может прекрасно знать — В ЧЕМ у него проблема (авто не едет, костюмчик жмет, система не так считает),
но решить ее САМ (как Вы правильно отметили) не в состоянии — попросту в силу того, что не умеет этого сделать…
Вы же сами не управляете самолетом, когда летите в отпуск на Канары :), хотя можете в тонкостях разбираться
в теории аэродинамики…
Но, наверное, наша дискуссия уже ушла от темы…
Обе статьи по большому счету — верные, просто для разных ситуаций.
Профессия «менеджер» (Руководитель проекта) не только есть, но является чуть-ли не центральным звеном в любой деловой деятельности.
Руководитель проекта — это тот человек который прежде всего выполняет следующие задачи:
1. Несет ответственность за выполнения проекта и получения по нему прибыли
2. Организует процесс предпродажной подготовки, выполнения и сдачи проекта.
3. Разрешает конфликтные ситуации с клиентом.
Руководитель проекта не раздает задачи! Он делегирует полномочия и ответственность на определенную деятельность сотрудникам.
Руководителю проекта совсем необязательно быть хорошим программистом, да и вообще программистом, но тогда у него должен быть тот сотрудник, которому он делегирует полномочия, в том числе, по определению способа решения учетных проблем, задач клиента.
На мелком проекте — должности руководителя, ведущего специалиста, программиста, консультанта обычно объединяются в одном человеке и это абсолютно оправдано. При этом он должен быть прежде всего программистом-консультантом, т.к. управлять ему все равно по большому счету некем.
На среднем проекте — обычно должности руководителя, ведущего специалиста — один человек.
На крупном проекте — руководить должен заниматься только руководством и не чем больше.
Нельзя одновременно быть и отличным программистом (консультантом) и отличным руководителем. А на крупных проектах руководитель должен быть только отличным. От руководителя в основном и зависит удачное завершение крупного проекта.
(84) Я уже понял, что так называемые «ответственные товарищи» просто принимают за ответственность ощущение собственной значительности. Понимание, что идиома «за базар ответишь» — в некоторых ситуациях не просто слова, приходит не не с возрастом, а с жизненным опытом.
(88) может быть, вы попробуете раскрыть п.1, первая часть?
может быть, вы попробуете раскрыть п.1, первая часть?
По поводу ответственности? Попробую (очень кратко):
Что такое руководящая должность — это прежде всего полномочия, с помощью которых может быть выполнена некоторая деятельность. Полномочия делегируются тем, кто над руководителем проекта (директор, рук. отдела, рук. направления и т.п.). Но вместе с полномочиями всегда должна идти и ответственность. Если есть какой-либо перекос в полномочиях-ответственности, то руководитель скорее всего или не сможет выполнить поставленные перед ним задачи, или не захочет их выполнять.
В чем выражается ответственность? Чаще всего в том же, что и для многих других должностей — «пряник-кнут»:
— Премии
— Повышения (или более интересные-крупные-прибыльные проекты)
— Увольнение
— Плохие / хорошие характеристики (известность) и т.п.
Просто если программист несет ответственность за написанный им функционал, то руководитель — за проект в целом. Разница есть? Если не чувствуете, то чем-то более-менее крупным не руководили.
PS в основном разница в объеме ресурсов (человеческих, финансовых, временных), которые затрачиваются на ту работу, за которую ты отвечаешь. Когда видишь, какое количество людей (в том числе важных тебе людей) зависят от твоей работы. Это и программисты-консультанты; это и сотрудники Заказчика. Одна моральная ответственность чего стоит.
(65)(68)(76)(84) о материальном выражении ответственности и о том что такое ошибки и кому они по силам а кому нет…
Расшифрую…
Не так давно взял на себя проект по 1С. Получил аванс.
В ходе проекта выяснился ряд нюансов которые не учел. Попытался все же решить проблемы за свой счет без напрягания мозга заказчику.
Убил пол года времени. Сделал проект на половину, т.е. оборудование и программа стоит, но обещанных функций не выполняет и нужную информацию не дает, хотя с виду все красиво. В моем понимании проект на половине это ноль.
Вернул все деньги заказчику обратно, все купленное оборудование отдал ему в подарок в качестве извинения за потраченное время.
Это один из примеров когда вина была явно моя, да и проект маленький, крайние тут быстро находятся.
Есть и другие примеры, когда проект провален, но причина то размыта… где то заказчик не сумел принять решение, где то побоялся, где то постеснялся, где то просто начал замыливать вопросы… проект провален… но брать эту ответственность на себя — мало приятного. Хотя и такое может быть.
Или тебе хочется чтобы руководителей именно расстреливали за ошибки? Если ты не в курсе то так думают только рядовые специалисты… любой успешный человек, который решал задачи чуть сложнее программирования и который хоть чего то в этой жизни добился, скажет тебе что все это достигается лишь ценой ошибок. Не ошибается тот кто ничего не делает (с) народная мудрость.
(92)
— Премии
— Повышения (или более интересные-крупные-прибыльные проекты)
— Увольнение
— Плохие / хорошие характеристики (известность) и т.п.
Это чисто зарплатная мотивация, от которой вы легко перепрыгнули (даже не заметив пропасти) к
«количество людей (в том числе важных тебе людей) зависят от твоей работы … моральная ответственность».
С моральной ответственностью люди, особенно «заслужившие» статус руководителя, договариваться имеют привычку, приобретенную опытом.
Смысл же моего замечания в том, упоминание о некоей особой ответственности РП в контексте темы оппонентами не раскрыто. А суть в том, что они полагают «ответственность» неким атрибутом, присущим им просто потому, что они чем-то руководят.
(94) Или тебе хочется…
Как однако любите вы переходить на личность.
Хочется мне, пожалуй, чтобы на ИС было поменьше необоснованных утверждений.
Тема была — почему валятся проекты. Вы прекрасно ответили: «выяснился ряд нюансов которые не учел»
Утешаю: не вы один. У всех этих проектов есть общая черта — демпинг со стороны РП.
А вот вернуть аванс и отдать, что купил, в данном случае как пример ответственности не принимается:
во-первых, все обстоятельства вы тут все равно не расскажете;
во-вторых, это, возможно, был самый дешевый вариант;
в-третьих, я полагаю, что вы не идете на каждый проект, с намерением все и даже больше вернуть, если не получится. и уж тем более я уверен, что эта конкретная «ответственность» вами в договоре не прописывается.
И вы ничего не сказали об ответственности перед своими сотрудниками.
(96) Так в том-то и дело, что никакой принципиально «особой ответственности» нет по сравнению с любыми другими профессиями нет, но есть 2 фактора:
1. возлагается на РП гораздо больше чем, допустим, на программиста. Как я уже говорил, объем ресурсов и значимость целей, фактически доверенных РП, достаточно велик по сравнению со многими другими профессиями.
2. при провале проекта, может серьезно подорваться востребованность РП, в том числе и у других потенциальных работодателей. Т.к. в этой среде (если РП крупный) предоставляется работа в основном только по знакомству.
Принципиально иная ответственность у бизнесменов. А у всех наемных работников, по большому счету, одно и тоже, что я и пытался написать в том сообщении, но, видимо, не донес.
То что я с «материальной» ответственности перескочил на моральную — так я трактат с плавными переходами писать и не собирался. А о моральной собственно написал только как важной для меня. У кого-то моральная ответственность выше, у кого-то ниже, у иных вообще нет. Все зависит от человека.
(105) программер из команды грохнуть может ту же самую базу, что и его РП
Востребованность — это опять таки мотивация из разряда зарплатных. Я же оспроривал «ответственность», преподносимую как нечто функционально, «ролево» (?) отличающее РП от члена команды. И показывал, что это — всего лишь самомнение.
То, что «особо крупные» РП — штучный товар, это во всех отраслях так. Я уже упоминал чубаса — провалил, гад, все, где пометился, и ничего. Связи,понимаешь. Ответственность — в терминах оппонента…
(106) а плюсь? 😀
(107)грохнуть базу может и уборщица неудачно вылив воду на сервер :). Ну и что дальше, что вы этим хотели сказать?
РП отличает от других членов команды только то, что он руководит остальными членами команды и отвечает за результат работы всей команды перед работодателем. И больше ничего.
То что многие упирают на «особую ответственность», видимо они имели ввиду, что ответственность крайне важна на любой руководящей должности. Это один из центральных факторов работы руководителя. Как я уже писал полномочия-ответственность, это то что определяет важность руководителя и, соответственно, его «зарплату».
А возможно путаница из-за того, что многие совмещают РП и бизнесмена, которому заказывают реализацию проекта. В общем случае это совсем разные люди. И не в коем случае не стоит эти должности путать. Но при этом, да, во многих случаях они совмещаются в одном человеке.
(108)Ну это уже совсем бред. Перед Исполнителем проекта (директор проекта, директор фирмы, которому заказывают реализацию проекта и т.п.) отвечает только РП и не кто больше. Да он может выслушать мнение РП о том, что в провале виноват программист. Может принять это к сведению, а может и нет. Когда РП берется за проект, он должен сам нанять программистов, или согласиться на тех, что предлагают ему. Если РП, что-то не нравиться из действий его начальства (навязывание людей, конечный вариант договора с Заказчиком, навязывание отношения к Клиенту и т.п.), он обязан тому об этом сообщить, и указать свое мнение, что это может привести к провалу проекта. Тем самым РП может снять с себя часть ответственности.
Любая деловая деятельность — это всегда жесткая иерархическая структура управления с множественным делегированием полномочия-ответственность. Если этого нет, то это говорит о неверном выборе кадров или ошибках в самой структуре управления или о непрофессионализме бизнесмена, который в конечном счете и рискует своими деньгами.
(89) Четвертый пост от Вас, и ничего кроме критики нет. А что-то по существу есть сказать? И упорно скатываетесь к «за базар ответишь»… Впрочем, Ваша жизнь, Вам решать.
Я говорю о способности взять на себя ответственность, без которой немыслимо заниматься управлением. А не о том, в чем эта ответственность будет заключаться в конкретном случае.
(1) Alraune, Соласен полностью. для себя вынес рациональные зерна с одной и другой статьи.
Я пишу инструкции конкретные: если документ — то для чего его использовать, если отчет — то что оно показывает. остальное — разумный пользователь сам догадается. А вот если работа постоена на процессном подходе — тогда нужно описывать для каждого участника процесса его работу на своем уровне.
(34)
Либо у вас не программисты в команде, либо вы им очень хорошо платите. Я не знаю ни одного программиста (именно программиста), который бы устроился в штат «писать инструкции».