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