「リモートチーム」を構築しようとして失敗した話 | TECHKNOW［テクノウ］
"StatusPage.io"では長いことリモートで仕事をしていた。僕はノースカロライナ、スコットはコロラドにいて、その状態で会社を始めた。そして６ヶ月後、ニュージャージーからダニーが加わることになった。 短い間だけど、同じ町に住んで仕事していたこともある。ダニーが加わって一ヶ月後にYCombinatorに参加し、その期間中はマウンテンビューで仕事をしていた。でもYCombinatorが終わった後、スコットと僕はそれぞれ元いた場所に戻り、ダニーはサンフランシスコに残った。 最初のうちはリモートで作業するスタイルに前向きだった。住みたいところに住んで、好きな時間に仕事をして、世界中から優秀な人材も雇える。とても快適で楽しかった。 しかし２年が経って、だんだんそのやり方が合わないと感じ始めてきた。だから、もう一度自分たちにあったやり方を変えることにした。 リモートチームのメリット・デメリット
泥沼プロジェクト振り返り
はじめに ちょっと前まで結構激しく泥沼化したプロジェクトにいた。 その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。 ある程度、月日が経って今なら もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。 振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか そういう立派なことが考えられればいいのだが。 とかく、Slide Shareとか世の中は成功事例は多く発信される。 けど、失敗事例のほうが共通して当てはまったりする。 前提 ・古典的なウォータフォール ・古典的なStruts1系ベース内製フレームワーク ・Java SE 6 ・QAとかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない
エンジニアとしての落としどころを作る | こえむの編集後記
コンピュータのエンジニアをやっていると、技術を高めたい、最新の技術を得たい、そして尖ったエンジニアになりたいと一度は思うものです。ただ、僕はそれらは諦めて、今年からは自分なりの落としどころを作ってやってみることにしました。 では、落としどころとは何なのか、です。のんびり考えていた中で、方針を決めてみました。 問題解決に関わる立場であり続けることを念頭に置く 最も効率よく開発・改善し続けられる技術を選択する 泥臭く・人懐っこくやる 仕組みを作る立場であり続けることを念頭に置く 僕はソフトウェアエンジニアとして転職を何度かしています。仕事をする中で、現在いる・過去にいた組織のどの上長も評価して頂いていたのは、人・お金・情報のバランスを取りながら、ソフトウェアを基盤にした仕組みを作って結果を出している点でした。 ソフトウェアエンジニアでありながら、最高の技術を導入したとか、最新の技術を普及させた
開発者の生産性：Noと言える技術 | POSTD
生産性を維持するのは難しいことです。 特に開発者の立場では。 ゾーン（超集中状態）に入るには時間がかかりますが、入ったゾーンから引きずり出されるのは簡単です。 例えば、 * ミーティング * Eメール * 作る予定の機能や、修正すべきバグ などに意識が分散されてしまいます。確認しておかないと、気付いたら何もする時間がなくなっています。 これを解決するための秘策があります： あらゆることに” no “と言うのです。 私たちのやり方をお教えしましょう。 ミーティングは木曜日だけ ミーティングは生産性を奪います。私たちは経験から、いつもミーティングの前後に45分の時間が消えてしまうことに気付きました。さらに、Skypeでのたわいないおしゃべりでも15分間が失われます。 45分後にミーティングがあると思うと、重要なことは始められません。同じように、電話やミーティングが終わってから、即座に大きな問題
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
