Category: технологии

отдых

Обо мне, и всем что тут есть.

Всем привет!
Меня зовут Бояршинов Алексей, я учредитель и директор ИТ-компании Корада, мы занимаемся автоматизацией бизнеса на 1С платформе. Наша работа, это не про бухгалтерию или кадры (хотя и это тоже мы можем), это скорее про бизнес-процессы, управленческий учет, бюджетирование, консолидированную отчетность, и индивидуальную (заказную) разработку.

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

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

Зачем заказчик делает ТЗ...

Иногда Заказчик пытается сделать ТЗ и прислать потенциальному исполнителю. Зачем он это делает? Мне кажется есть несколько причин:

  1. Надеется таким образом снизить стоимость проекта (все знают, хорошее ТЗ это же половина дела)

  2. Пытается получить от подрядчика точную оценку срока и бюджета

  3. Обязан дать ТЗ для того чтобы провести тендер (документ нужно подать тендерному комитету)

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

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



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

Что же делать? Если обязанности писать ТЗ нет (для тендера и т.д.), лучше написать ФТ или юз-кейсы (как пользователи должны работать в системе шаг за шагом). Но кто же меня услышит? )) 
отдых

Технологии сохранения знаний в организации..

Что-то у меня в последнее время ответы на посты друзей получаются массивные :)

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

Кстати, странно что комментов на пост нету.

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

Все верно? неоспоримо?

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

Давайте представим условную такую ситуацию. Решили мы создать технологию передачи электроэнергии на расстояние, без проводов, и без потерь. Или, чего уж мелочиться, телепорт решили сделать, чтобы сотрясти всю мировую экономику :))

Для этого наняли лучших ученых физиков, химиков, атомщиков...  собрали их в офигенном научном центре. И тут пришла нам в голову мысль, а что же с их "tacit knowledge"?? А вдруг уйдет кто, и его бесценные знаний "в голове" для нас пропадут. Сейчас мы сделаем систему, в которой по шагам пропишем процесс придумывания телепортатора, чтобы если наши нобелевские лауреаты нас покинут, мы могли взять кого-нибудь другого, вооружить его инструкцией, и ничего не потерять.

Кажется, получилось описать достаточно бредовую ситуацию? )))



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

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

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

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

Так что же, я считаю что нет способа сохранения и увеличения знаний в компании?
Есть конечно.

Это те самые правила, регламенты и пошаговые процессы плюс комплекс мер, направленных на создание кадровой политики, увеличивающей "срок жизни" сотрудников внутри компании, стимулирующей их развитие, обучение и рост.

Как думаете? 
отдых

Технологии эффективности: метод Франклина


 

Есть такая область знаний, называется "техники принятия решений". Их вообще то много, сегодня опишу самую, как мне кажется, простую.

 

Допустим, есть у вас вопрос, на который есть два различных возможных ответа, и вам надо выбрать один из них. Может быть, это "Да"/"Нет", может это "Продать"/"Не продавать", а может "Взять на работу Васю"/"Взять на работу Петю".

 

В общем и целом ситуация ясна - есть альтернативный выбор, в голове крутится куча аргументов "за" и "против". В один момент вам кажется, что аргументы за первый вариант однозначно перешивают, но как только вы почти-почти-окончательно принимаете решение по нему, в ваш мозг закрадываются смутные сомнения, а все ли недостатки/достоинства вы учли, чаша весов начинает склоняться в сторону варианта два, и вот уже БАЦ, вы считаете его однозначно правильным. Ну почти-почти. Далее процесс повторяется (до морального и эмоционального утомления вас и окружающих).

 

 

Collapse )

 

 

ПС

А какими методами принятия решений пользуетесь вы?