良かったことは良かったとはっきりフィードバックする - $shibayu36->blog;
最近心がけていることとして、「良かったことは良かったとはっきりフィードバックする」ということがある。 自分がリーダーやマネージャのポジションになった時に、方針やメッセージを打ち出す、チームの開発フローを改善するなどを行うことがあった。この時、何もフィードバックが返ってこなくて、結局良かったのか、それともあまり興味がないのか、実は不満に思っているのか、どれなのかわからず、非常に不安に思ったという経験がある。 逆に自分が伝えられる立場になった時を考えてみると、何かが行われた時、気になることはよくフィードバックするけど、良かったなと思うことは心の中で思うだけでフィードバックしないことが多いと感じた。 そこで最近は、「良かったことは良かったとはっきりフィードバックする」ように心がけている。はっきりフィードバックするというのは、どこが良かったかを出来る限り具体的に相手に伝えるということである。伝える
7年働いた時点での私の仕事の極意 - Kengo's blog
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
テストを書く文化を育てる戦略と戦術
at DevLOVE現場甲子園2013 2013/11/09 (土) http://http://devlove.doorkeeper.jp/events/5464Read less
Node.jsの問題点、デメリットと解決方法まとめ - Qiita
技術選定のためや、俺が問題解決するぜっ!的な人向け。 順次解決されると思うので、順次更新します。 以下に上げたものも、解決策があるものが多いです。 はじめてのNode.js (2013年3月26日初版) どこか1か所CPUリソースを多く消費するような重い処理が入ると、全体のパフォーマンスが低下する マルチコア/マルチCPU環境を十分に生かすことができない コールバックを多用するためにコードが複雑になる merittyの記事 (2012年12年23日) Node.jsのメリットとデメリット | meritty [メリッティ] JavaScriptの限界、オブジェクト指向が不完全 マルチコアサーバで性能を十分に発揮できない 文法エラーが、サーバーの停止を引き起こす あるリクエストに問題があると、他のリクエストをブロックする ZEALOT社員の方 (2012年10月29日) 引用: Node.j
できるエンジニアだけで組織をつくる - ワザノバ | wazanova.jp
http://www.slideshare.net/bcantrill/surge2013 上記のスライドは、JoyentのSVP, EngineeringであるBryan Cantrillがエンジニア組織のあるべき姿ついてまとめたものです。BryanはSun Microsystems出身で、同社がOracleに買収されたのを受けて、2010年にJoyentに移ったという経歴。Joyentはクラウドサービスの会社ですが、Node.jsのスポンサー企業として知られ、Node.jsの中心人物であるIssac Schlueterなどフルタイムでオープンソース開発に従事する社員がいます。昨年、Greylock, Intel CapitalなどからSeries Dラウンドで$85Mの資金を調達してますので、投資家からは上場を期待されていると思われます。 彼の意見としては、 [モチベーションをあげるポ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スタートアップにjoinして安心して眠るためにやった5つのこと