1) Никогда не работай без страховки.
Если Вам предстоят какие то изменения, будь то технические (апгрейды, патчи, обновления, замена оборудования и т.д.) или организационные (переезд, новые сотрудники, отпуска, обучение и т.д.), то всегда нужно иметь страховку, на случай если что-то пойдет не так. Всегда должна быть возможность отката/переключения/восстановления. Никогда не стоит начинать работу, если Вы не знаете что делать, когда все сломается.
2) Время бежит.
Не стоит забывать, что в случае инцидента, аварии или другой проблемы, во время ее исправления/поиска причин, стрелка на часах движется в 2 раза быстрее. А работу Вы делаете в 2 раза медленнее. Всегда стоит помнить об этом. Поэтому когда перед Вами стоит задача, подумайте сколько времени Вам нужно на ее исполнение, умножьте цифру на 2 для себя, а значение, умноженное на 3 сообщайте заказчику.
3) Имей всего по 2 штуки.
Эту фразу стоит воспринимать очень буквально. Нужно дублировать все. Оборудование (2 СХД, 2 сервера, 2 коммутатора и т.д.), бекапы, сотрудники, рабочие станции, планы. Всего должно быть 2. Ну или нужно по крайней мере к этому стремиться.
4) Плохие новости не становятся лучше со временем.
Когда происходит какая-то проблема, не стоит тянуть с тем, чтобы озвучить ее коллегам/клиентам. От того, что Вы сообщите о недоступности сервиса/человеческой ошибке/отказе оборудования позже эта новость радостней не станет.
5) Больше коммуникации!
Нужно общаться больше, чем Вы это делаете сейчас. Нужно слать больше уведомлений. Нужно слать больше писем. Нужно делать больше звонков. Поверьте мне, любой клиент, у которого наблюдается проблема, предпочтет получить пару дюжин писем со статусами (пусть даже и одинаковыми), а не думать, что Вы ничего не делаете, снять трубку и позвонить Вам с вопросами.
6) Ошибаться нормально.
Об этом тоже не стоит забывать. Делать ошибки абсолютно нормально. Если Вы следуете другим правилам, то ошибка для Вас не будет катастрофой. Но вот делать ту же ошибку во второй раз — уже нет. Это значит, что есть проблемы с документацией/коммуникацией/людьми.
7) «Потому что мы всегда так делали...»
Про использование этой фразы стоит забыть. Никогда не решайте вопросы, следуя этим словам. Даже если у Вас уже что-то прижилось (техническое решение, процедура, методы и т.п.), не нужно отказываться от лучшего, потому что боитесь перемен.
8) Встречи.
Я, персонально, не люблю встречи. Все эти переговорки, обсуждения на меня давят. Но, к сожалению, встречи это вынужденное зло. Без них никак. Обязательно проводите периодические встречи (встреча отдела, митинг подразделения, квартальная общая встреча и т.д.). Помимо всего встречи с клиентами тоже важны. Не забывайте периодечески показывать клиенту что Вы для них делаете, как улучшаетесь и почему именно Вы такие молодцы.
9) Никогда не забывайте о здравом смысле.
Это, пожалуй, одна из самых важных вещей. Если Вы где-то замечаете отсутствие здравого смысла (в документации, в процедуре апгрейда на сайте вендора, в указании начальства, в договоре) — остановитесь и переходите к пункту 5 (больше коммуникации). Не стоит слепо принимать решения, если Вам кажется, что тут явно что-то не так.
Также хотелось бы сказать о нескольких моральных принципах, которым тоже неплохо бы следовать:
— Если ты сказал, что что-то сделаешь, делай именно так, как сказал
— Выполняй взятые малые и большие обязательства перед коллегами и клиентами
— Будь проактивным в действиях и коммуникациях
— Лучше горькая правда, чем сладкая ложь (старайтесь не обманывать клиента. К Sales не относится :D )
— Сделайте так, чтобы Вас было видно и оставайтесь на связи
Конечно невозможно всегда и все выполнять, но лучше знать, к чему ты стремишься. И когда ты хочешь принять какое-то решение, и чувствуешь, что оно неправльное — еще раз посмотри на список.
взято с хабра: http://habrahabr.ru/post/196176/
Прошлые записи
- Комната призвания
- Разбираемся с Coroutine в Kotlin - часть четвертая
- Разбираемся с Coroutine в Kotlin - часть третья
- Разбираемся с Coroutine в Kotlin - часть вторая
- Разбираемся с Coroutine в Kotlin - часть первая
- Отпуск длинною в год
- Подходит ли data class для JPA Entity?
- События как источник правды или как я в стартапе участвовал
- Код 2015 против 2023
- Jvm Internals - Перевод
- Мозг против живота или насколько трудно управлять своей жизнью