Специфика крупных внедрений и как в них выжить специалисту 1С

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

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

О проектах внедрения

Давайте немного определимся в терминологии – когда я говорю «крупное внедрение», я имею в виду внедрение решений на базе 1С для крупного бизнеса, государственных компаний, или корпораций.

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

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

• сработавшуюся команду, в которой налажено взаимодействие, все друг друга знают и знают, кто за что отвечает;

• выстроенные коммуникации;

• организованные процессы;

• у команды есть компетенции по работе с этой системой;

• у нас есть более-менее стабилизированная инфраструктура.

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

Например, если разработчик приходит в начале проекта, он спрашивает: «А где у вас таск-менеджер?» А его пока не развернули, чуть позже развернут. Но разработчик уже не понимает: «как это, а как работать»?

Или аналитик приходит – к кому ему обращаться со сложным вопросом? Непонятно. Он просит: «Дайте мне должностную инструкцию». А ее еще нет.

И для того, чтобы специалисту 1С на проектах внедрения работать эффективно, он должен:

• во-первых, быть готовым к тому, что он столкнется с этими трудностями;

• во-вторых, уметь их преодолевать.

Об этом я немного расскажу.

Факторы, формирующие специфику крупных проектов

Расскажу о некоторых факторах, которые влияют на специфику крупных внедрений 1С.

• Проектная работа подразумевает под собой необходимость сделать уникальный продукт в ограниченные сроки и в ограниченный бюджет. Это довольно непростая задача, которая подразумевает высокие требования к качеству проектного управления, правильный выбор методологии (waterfall или agile), спринты, дедлайны и все вытекающее.

• Все это усугубляется масштабами – например, проект на 10 человек может сделать один руководитель. А проект на 300 человек один руководитель уже сделать не может. Формируются группы различной организационной структуры, с которыми сложно работать. Когда приходит новый человек, он не понимает, к кому по какому вопросу бежать – у него в голове может возникать путаница. Поэтому на крупных проектах важно обязательно ввести какую-то базу знаний, план коммуникаций, чтобы новый человек, приходя в компанию, сразу понимал, кто за что отвечает, и к кому ему бежать.

• Привычные процессы, которые работают на небольших проектах, перестают работать на больших масштабах. Например, процесс согласования – вы можете согласовать в почте 10 документов, но 10 тысяч уже не можете.

• То же самое касается управления разработкой – небольшой проект внедрения вы можете сделать в чистой waterfall методологии. Но на крупном проекте изменчивость и продолжительность слишком велика. План работ по проекту громоздкий и требует огромных ресурсов для пересчета, а пересчет требуется часто. В итоге не редка ситуация, когда план теряет актуальность и проект продолжает движение уже без него, что ни к чему хорошему не ведет. Поэтому часто мы применяем гибридные технологии управления разработкой: когда верхнеуровневый план проекта (вехи и основные задачи) строится в waterfall методологии, а внутри групп разработки уже применяется agile. Это позволяет сохранить гибкость на уровне конкретных задач на разработку (agile), но при этом удерживать проект в изначально заданных рамках (waterfall).

• Часто возникают проблемы с организацией и автоматизацией внутренних процессов проекта. Потому что в условиях высокой неопределенности инвестиции в это очень рискованны. Например, вы можете принять решение о развертывании системы электронного согласования проектных документов. Но, пока вы в неё вкладываетесь, разворачиваете, внедряете, оказывается, что такая система уже есть у Заказчика и использовать нужно её, а не вашу. Или, например, вообще решено заморозить проект. Все труды и ресурсы – в трубу. Поэтому проектное управление часто не торопится выстраивать, систематизировать и автоматизировать молодые процессы. Могу сказать, что здесь важен баланс – бежать впереди паровоза не нужно. Но игнорировать эти задачи нельзя тем более. Много примеров, когда масштабные проекты, так и не внедрив должным образом автоматизацию внутренних процессов, годами терпят огромные издержки.

• Возникает более жесткое разделение труда, и сотрудника, привыкшего быть человеком-оркестром, могут во многом ограничить. Например, человек приходит из фриланса или еще откуда-то, где он занимался буквально всем, а тут он попадает в ситуацию, когда от него ждут чего-то одного. Это может быть непривычно. Нужно быть готовым, что у вас будет конкретная роль, шаг влево, шаг вправо – уже не ваше.

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

К чему нужно быть готовым на крупном внедрении

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

2. Высокий уровень изменчивости и неопределенности. Понятно, что мы делаем уникальный продукт, а это поиск и постоянное изменение.

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

4. Работать приходится в условиях строящихся коммуникаций и процессов.

5. Возникают организационные сложности.

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

Резюмируя по всем этим пунктам, могу сказать, что о зоне комфорта на крупном внедрении можно забыть – это не про зону комфорта.

Топ 6 soft-skills для внедрений

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

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

• Гибкость. Границы и направления проекта меняются часто, управление “переобувается” на лету. Поэтому надо уметь подстраиваться под сложившуюся ситуацию и иногда переступать через себя, чтобы все-таки добиться результата.

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

• Стрессоустойчивость – это понятно.

• Про тайм-менеджмент подробнее расскажу на следующем слайде.

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

Когда тайм-менджмент важен?

Про тайм-менеджмент у меня немного сумбурный слайд, попытаюсь объяснить, что я имел в виду.

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

Эти человечки находятся в разных ситуациях загрузки.

• Пока недогруз, тайм-менеджмент не нужен, вы все будете успевать (первый черный человечек).

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

• При небольшом перегрузе это тоже вам не сильно поможет – вы и так сможете разобраться, какая задача важная, какая неважная, и важные задачи все-таки сделать (второй черный человечек)

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

• Внизу желтенький человечек, который тайм-менеджмент использует. Я здесь обратил внимание, что он делает только две задачи. Остальное время он тратит на то, чтобы вести календарь, планировать, делегировать и применять прочие методики, в которые я сейчас углубляться не буду. Эти действия занимают время, но позволяют ему из этой кучи задач сделать те, которые действительно важны. Т.е. желтенький человечек делает меньше, но то, что нужно.

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

Главное – мотивация

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

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

Когда вы устраиваетесь на новую работу или беретесь за сложный проект, в первую очередь спросите себя, насколько это вам интересно, насколько вас мотивирует эта работа, эта задача, этот вызов. И уже только после этого делайте выбор.

Выделю три основных вида мотивации специалистов:

• Первый – это финансовая мотивация (деньги, лобстеры и прочее).

• Второй – это мотивация страха. Она работает и часто применяется в компаниях, хотя я это вообще не поощряю. Человеку говорят: «Я тебя уволю, премии лишу», и человек побежал работать замотивированный. Это, конечно, не то.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.