Коли ви востаннє відчували страх на роботі? Українські розробники розповіли DOU про робочі жахастики, серед яких телепортація до юрського періоду мобільної розробки, помилка в одному рядку коду, що мало не коштувала їм $100 тисяч і раптову зупинку цілого заводу через економію роботодавця на тестовому завданні.
Чи потрібно CTO програмувати? Здавалося б, головне в бізнесі — добре керувати людьми та вміти продати свій продукт. Та чимало розробників, які доросли до посади технічного директора, продовжують програмувати. Навіщо вони це роблять, що це дає особисто їм і команді, чи не заважає написання коду добре виконувати адміністративні функції та в яких ситуаціях краще припинити цим займатися ми запитали у СТО та директора локального офісу IT-компанії.
Олексій Остапов понад 12 років працює в IT і часто повторює слово «тестування». Як і багато інших людей, боїться нафакапити та відчути на собі осуд колег, друзів, рідних. І в його роботі часто факапи настають саме через страх їх зробити. У статті поговоримо про те, як перестати боятись і припускатися помилок цілеспрямовано.
Найм недостатньо кваліфікованих спеціалістів може призвести до того, що директору компанії доведеться працювати цілодобово. Якщо домовитися з інвестором усно та не зафіксувати домовленості письмово, є ризик раптово втратити половину фінансування компанії. CEO українських IT-компаній розповідають про свої факапи із запуском нових продуктів, наймом людей, плануванням, комунікацією з клієнтами та діляться висновками з них.
Надто багато заморочувалися з дизайном, тягнули із виходом на ринок, не розумілись у маркетингу й не знали, як знайти клієнтів та інвестування — таким є неповний список того, з чим стикнулись чотири розробники, працюючи над власними стартапами.
Зрештою наші герої були змушені закрити бізнес або відмовитись від його розвитку. Розповідаємо про їхній досвід, помилки й те, як запобігти схожим провалам у майбутньому.
Якщо роками розробляти продукт і не пробувати продавати його, є ризик втратити мільйони доларів. Якщо неправильно обрати бізнес-партнера, може виявитися, що вам доведеться піти. CTO компаній розповідають про власні факапи — технічні, комунікаційні та менеджерські — та чого вони їх навчили.
Робочі провали змушують сильно стресувати та робити з них висновки. Під час першого релізу на новій роботі можна добре протестувати всі дрібниці, але пропустити найважливіше; можна не помітити, що половина текстів у застосунку китайською мовою, а не японською. Трапляється всяке. QA-спеціалісти поділилися власними факапами й тим, як вони змінили їхній підхід до роботи.
Фейлят все — и большие компании с опытом, и маленькие «зеленые» фирмы. Не фейлить невозможно. Проваливать проект — это не плохо, плохо выходить из проекта, не взяв на себя ответственность. Артем Ганжа, СЕО iSKY.solutions, рассказывает о факторах, которые повышают вероятность фейла и что делать, когда что-то пошло не так.
Сергій Колін, Director of Technology в Onix-Systems, розповідає про те, як виникла проблема через використання в застосунку іконки, схожої на ту, яка є в YouTube. А потім розробники й взагалі втратили доступ до облікового запису, під яким було створено проект.
«Fail review» — рубрика, в якій ми збираємо історії про робочі провали: що відбулось, як виправляли і які висновки зробили.
К финансовым потерям мы уже привыкли. Не проданный продукт, ошибка в расчете и недовольный клиент — это те последствия, о которых мы в курсе. Но что, если наши ошибки приведут к непоправимым последствиям.
Фейлы на собеседованиях — это бесконечная тема. Первая статья получила много откликов, поэтому продолжаем.
В след за статьей «Неудачные собеседования: история одного тестировщика», получившей много откликов, мы решили раскрыть тему детальнее и пригласили читателей поделиться своими историями.
«Fail review» — новая рубрика, в которой мы собираем истории о рабочих провалах: что произошло, как исправляли и какие выводы сделали.
Так или иначе, фейлят все. И это нормально. И даже более того, это хорошо!
Комментарии