Блог Александра Башкирова

ИТ и бизнес, компьютеры и ПО, фото, программирование и просто мысли…
Этот сайт в основном посвящен тому, что мне интересно вне работы. Ведется в порядке хобби.
Все изложенное на сайте - мое частное оценочное мнение и не может быть истолковано иначе.
Со всеми вытекающими из этого последствиями.

эффективность

E-xecutive: 6 токсичных типов сотрудников, отравляющих компанию

Просмотров: 573Комментарии: 0
Работа

На E-xecutive попалась интересная статья: 6 токсичных типов сотрудников, отравляющих компанию.

Я вот лично сталкивался с каждым из этих типов. Даже не скажу сразу, какой тип наименее приятен... наверное, всё-таки "Неприкасаемые". Обычно у этих ребят достаточно власти (и дурь, увы, тоже не редкость), чтобы сделать как лучше. Ну а дальше - известный принцип: "не надо мне делать как лучше, сделайте как хорошо". Второй - "жертвы", через их объяснения о невозможности простейшего действия порой не пробиться и с тараном... остальные в моем личном антирейтинге помечены как более безобидные.

И да, интересный вопрос от себя к себе - а я случаем, не в их числе? Вот не хотелось бы...

Павел Алферов: концепция контрольных точек

На Ютубе - отличное интервюью, которое дал Павел Алферов Павлу Софронову, по разработанной им методологии РИМ-3, и, в частности - по концепции контрольных точек. Что очень здорово - Павел прямо и открыто говорит об особенностях национального проектного управления. И о том, как эти особенности "вписать" в живой проект. Честно - восхищен, тем более, что знаю, "как это работает".

Ссылка на интервью:

https://www.youtube.com/watch?t=130&v=BB-TUZ_iHkw

Само интервью:

Пост про то, как надо писать ТЗ

Периодически мне приходится в том или ином виде консультировать разные компании по поводу такого замечательного документа, как техническое задание на информационную систему.

И часто встречается ситуация, когда в роли ТЗ выступает все, что угодно... кроме, собственно, ТЗ. Почему так? Да потому, что ТЗ - это задание, на основании которого должна быть подготовлена система автоматизации. Не более - но и не менее. В роли ТЗ в общем случае не могут выступать прототипы экранов, список пожеланий и т.д. - потому что в итоге получится нечто, соответствующее ТЗ - но полностью или частично не соответствующее ожиданиям заказчика. Как избежать такой радостной ситуации?

Во-первых, всегда помнить - система, разрабатываетмая по ТЗ, автоматизирует процесс (напомню, речь идет о ТЗ на информационную систему - от интернет-магазина до ERP). Соответственно, в ТЗ обязан быть прописан процесс, который автоматизируется. Иного просто не дано: не понимая процесса, невозможно описать систему.

Второй аспект: ТЗ должно описывать результат "на выходе". И из этого следует еще один очень важный вывод: в ТЗ должны присутствовать варианты использования системы. То есть, должно быть описано, кто (какая роль) выполняет какой надор действий в системе. Да, и это должно коррелироваться с процессами, которые система автоматизирует.

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

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

Следующее, что нужно для разработки ИС - определить этапность. Что делаем и что запускаем в первую очередь, что - во вторую и т.д. Это очень важно - так как позволяет четко очертить пожелания Заказчика к тому, что должно работать в первую очередь, а что должно быть запущено в последнюю очередь. Кстати, если есть сроки - то им место тут же.

Дальше, собсвтенно, если есть понимание на какой базе строим ИС - нужно расписать это. Если ИС создается "с нуля" (бывает и такое) - то указать, на каком яыке она пишется, какие библиотеки требует и т.д.

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

Дальше, нужно описать, что надо будет сделать, чтобы ввести систему в эксплуатацию.

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

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

Финальным аккордом нужно описать процедуру приемки-передачи системы (в целом и по каждоому этапу). А также привести требования к информационной безопасности.

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

В общем, получился почти на тему "как написать ТЗ" :) И, прошу отметить - никакого ГОСТа. Хотя структура получилась в чем-то похожей на то, что трбует ГОСТ 34 от ТЗ. Но, наверное, его проектировали, исходя из аналогичных (или в чем-то похожих) соображений.

Про удаленную работу, ИТ и обобщая опыт...

Просмотров: 1460Комментарии: 4
Работа

Итак, опять про работу :) Так получилось, что по долгу службы несколько раз мне пришлось налаживать взаимодействие между территориально распределенными офисами, а еще один раз - выступать в роли заказчика удаленной работы (то есть работать с фрилансерами и удаленными подрядчиками).

Основной вывод - эффективная удаленная работа возможна! Условие/дополнение: возможна, при наличии адекватных людей как со стороны Заказчика, так и со стороны Исполнителя.

Поясню. С моей точки зрения, при организации удаленной работы как в случае распределенных офисов, так и в случае работы с фрилансерами есть одно общее правило: работа строится по принципу сервисной модели. По сути, это означает, что одна сторона предоставляет другой сервис (разработки ПО; создания документации; анализа и т.д.). В роли SLA в этом случае выступает договор, в котором зафиксированы обязательства каждой из сторон. Конечно, если это не взаимодействие офисов - тогда роль SLA играет либо устно сформулированные, либо зафиксированные на бумаге правила: такие-то запросы отрабатываются тогда-то, такие-то - тогда-то и так далее...

Тут надо вспомнить, что в самом безупречном договоре бывают "дыры". Без этого никуда - невозможно в юридическом документе предусмотреть все возможные варианты.... после чего вспомнить про требование "адекватности". Оно в общем имеет два аспекта:

  1. "Нормальный режим", когда сервис предоставляется в штатном режиме, то есть подпадает под "SLA" (скобки - потому что SLA может быть совсем не SLA - я писал об этом выше);
  2. "Нештатный режим", когда сервис предоставляется "за рамками SLA" - то есть не когда SLA нарушается, а именно, когда требуется что-то, что в "SLA" не входит;

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

Если же чуть отойти от "людей", то вторым важным фактом является обеспечение коммуникации. Это и "голос" (достаточно, кстати, Skype или корпоративного SIP) и общее защищенное хранилище файлов, и система документооборота (не обязательно все сразу, и в зависимости от задач - могут быть варианты), и - самое главное - желание их использовать. Опять упираемся в "адекватность".

Получается - "кадры решают все", и в этом был прав Лучший Друг Советских Физкультурников?

Треш в Пулково-1

Просмотров: 1429Комментарии: 0
Работа

Так получается, что частенько летаю утренними рейсами из Пулково-1. И, доложу я вам, место сие утром - аццкий треш. Особенно - в части прохода предполетного досмотра.

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

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

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

В общем, летать хорошо - но лучше ездить Сапсанами или ночными поездами (если в Москву и есть билеты).

Ну и надеюсь, что новый терминал будет лишен подобных "прелестей", а будет .. ну хотя бы как Домодедово: быстро, спокойно и относительно удобно.

Люди - "черные дыры". Недоумения пост.

Просмотров: 2977Комментарии: 0
Работа

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

Пишешь такому человеку письмо. Пишешь, отправляешь. В ответ - многозначительная тишина. Пишешь еще раз. Результат примерно тот же.

Я бы понял, если бы те письма содержали побуждения человека сделать что-то. Но нет:) Это были письма, в котором содержались просьбы, выполнение которых было выгодно получателям.

Отдельная песня со Скайпом. Есть у меня там такой вот "черный дыр". Все ответы приходят с завидным опозданием. Три часа - минимум. (Хорошо, что вообще отвечает, да?) Причем, судя по рассказам общих друзей - он со всеми так )))

В общем - недоумеваю я. Чего это они так, а?

Жизнь в эпоху копипастинга

Просмотров: 1430Комментарии: 0
IT Blogs

то будет странный пост... поток сознания:)

Итак, мы живем в эпоху глобального копипастинга. Копипастингом пишется код. Ооочень часто. Сознаюсь: у меня иногда хватает времени на то, чтобы сеть и кодировать. Так вот, в том, что я скромно именую "моя CMS" примерно 70% "моего" кода, и около 30 - копипастного. Я такой код обычно оформляю в отдельные файлики, складываю его в отдельный каталог, и всегда пишу - откуда стянуто... это не к тому, какой я хороший. А к тому, что когда попадается задачка уровня первого семестра "программирования" технического ВУЗа для непрограммистих специальностей, мне проще погуглив найти решение, чем думать.Времени точно займет меньше. Как показывают наблюдения, я не одинок: знакомые (программисты и другие ИТшные жители) говорят, что копипастится все: от конфигов до кода.

....А как же любимая всеми команда man? - грустно вздохнул серый ослик Иа-Иа.

да, да - и "мире linux" копипастинг тоже набирает обороты. "Не знаешь как? - скопируй"

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

- Где? - спросите вы.

- А вот видел. Не в родной компании, слава Богу. Но - видел. Причем грамотно так вписано в текст,  если бы в свое время не освоил книжку, которая была скопипащена - мог бы и не заметить: талантливый автор документа писал в стиле авторов книги. Видел не по работе - знакомый попросил помочь оценить документацию.

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

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

Кросспост из моего ИТшного блога на ITBlogs.ru